Valve Rolls Out Wine-Based “Proton” for Running Windows Games on Linux(phoronix.com)
phoronix.com
Valve Rolls Out Wine-Based “Proton” for Running Windows Games on Linux
https://www.phoronix.com/scan.php?page=news_item&px=Valve-Steam-Play-Proton-Linux
329 comments
And here pretty much lies the gist of it - most issues I've ever had with Linux gaming wasn't due to ports, but due to really poor driver quality and support from the platform. Missing OGL extensions, broken features or partly-implemented features made games unplayable.
Is that really a problem these days ? Nvidia has had very good Linux drivers for a long time and in the recent years, Intel and AMD has made great improvements.
I go with AMD to have the open source driver and things aren't perfect but I knew what I was getting into. A year ago Mankind Divided worked great but Total War: Warhammer had horrid graphics glitches. Today both work great. I really wish there were some sort of registry of which games work on which drivers for Linux...
Not directly drivers but Linux overall: https://appdb.winehq.org
Some people post which drivers they used, especially when it didn't work.
Some people post which drivers they used, especially when it didn't work.
To add to this, it's really easy to add your experiences to the database.
If you get a game to work, take the time to head over and add your experience.
If you get a game to work, take the time to head over and add your experience.
[deleted]
I've had severe issues and glitches even these days (granted I have an nVidia card because AMD drivers were a dumpster fire at the time of purchase) and even things like fullscreen mode doesn't always work reliably depending on the screen (external/internal) and other settings.
It's not. Drivers are pretty good nowadays and for AMD last year has seen huge strives in quality and performance of drivers with Mesa.
nvidia's drivers are pretty good, but at least for me they seem to cause crashes with libavcodec on certain video formats. That's linux on the desktop for ya...
Nvidia was probably the best you could get at the time, but better buy AMD next time. The AMD drivers are very good and don't have the integration issues of Nvidia's.
The last time I ran AMD I had even weirder issues than nvidia. The card+chipset I had was not supported by Mesa, though. (It was a triple monitor setup on two display adapters, both AMD)
Too bad, I'm pretty happy with my nvidia card...
Too bad, I'm pretty happy with my nvidia card...
I don't know when was the last time you looked but AMD has mainline drivers now and have contributed a lot of general purpose code for other drivers to use.
I don't know the details of this stuff, but with .net/mono is it even correct to call it emluation? It seems more like a compatability layer than emulation.
Given the most AAA games are written in native C++, I don't see how mono makes much difference at all. No .net CLR or mono are used at all in those cases.
The only major platform using C# is Unity, and there are a few AAA games written in it, like KSP.
The only major platform using C# is Unity, and there are a few AAA games written in it, like KSP.
Most of the newer games I play are Unity games. Although checking Wikipedia it sounds like the core engine is still in C++, so maybe there is more emultation than I thought even then. I guess this is why not that many games can be run directly with mono...
I found someone did a HackWeek project at Unity this year of porting the Unity engine to .net core that has more details:
http://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr/
I found someone did a HackWeek project at Unity this year of porting the Unity engine to .net core that has more details:
http://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr/
Unity's C# gets compiled to native code via IL2CPP.
Except that the availability of emulation may cause developers to stop native linux support. I dont want to hear "talk to valve about your linux issue" every time i report a bug.
Native means nothing. Nobody rewrites DX engines to OpenGL from scratch. If you believe so then you have been lied to. Feral interactive uses InDirectX to translate DX calls, VP has eON which is very similar... Everyone is doing it already.
I don't know if this is what you meant, but plenty of game engines definitely have separate backends for Direct3D and OpenGL that are more than just translation shims.
There's the big ones like Unreal, Unity, etc. The same is true of smaller in-house engines I've seen and worked on. Even open source hobbyist-driven engines like Godot have multiple renderer backends.
It is true that there is a fair amount of translation going on (browsers and ANGLE is a big example, along with the recent MoltenVK) but it's by no means the only way people do things.
There's the big ones like Unreal, Unity, etc. The same is true of smaller in-house engines I've seen and worked on. Even open source hobbyist-driven engines like Godot have multiple renderer backends.
It is true that there is a fair amount of translation going on (browsers and ANGLE is a big example, along with the recent MoltenVK) but it's by no means the only way people do things.
Middleware engines yes. But not all AAA games rely on those. And you know what? Most games using Unity for example dont get Linux ports even though it should be relatively straightforward in many cases. So in practice, DirectX is the main renderer used everywhere on PC.
Wow. HN is so literal. Without expanding upon ever tiny definition, take "native" to mean a linux release developed, beta-tested, and supported by the original developer. Not something developed for windows and then expected to just run on linux boxes thanks to a compatability layer.
KSP, factorio, prison architect, they all put considerable efforts into native linux support. I'd hate to see that be outsourced to valve's compatability layer(s).
KSP, factorio, prison architect, they all put considerable efforts into native linux support. I'd hate to see that be outsourced to valve's compatability layer(s).
> KSP, factorio, prison architect, they all put considerable efforts into native linux support. I'd hate to see that be outsourced to valve's compatability layer(s).
Nothing prevents developers from making specific Linux clients. Valve just provides the option for when clients are not available. Nothing to lose, really.
Nothing prevents developers from making specific Linux clients. Valve just provides the option for when clients are not available. Nothing to lose, really.
He claimed that developers could become lazy and simply stop making specific Linux clients, he never claimed that this additional option could prevent developers from making specific clients.
Most developers already dont produce Linux ports. Even indies. So thats the current sad state of affairs. We tried. It does not work well so it was kind of obvious a WINE based solution would have to come sooner or later.
Well, other than companies just not bothering with making specific Linux clients, and relying on Valve. And then when something doesn't work, the developers brush it off and say, "not my problem".
We already know what the current state of Linux gaming is like. Almost nobody apart from 20 percent of indie gamers make Linux ports, there are no AAA games apart from rarely a few ports from Feral every year, its not going anywhere. In the meantime with DXVK i was able to play several DX11 titles as if they were native. This is the only way to go.
The thing is just because a few take the time to do that doesn't mean most developers do and it seems like most don't want to take the time to do so. But, more developers may be interested in using an emulation layer if it's supported and easy for them to use. If developers see their titles being purchased and played more on Linux systems because of this, this gives them more incentive to put more effort into developing native Linux clients and providing proper support.
The way I see it, devs aren't obligated to support any system they don't want to. I really appreciate the ones that take the time to support Linux natively, or even by using an emulation layer because I realize they don't have to. If this makes more developers realize Linux is a viable ecosystem for them to make games for. Even if it's just through an emulation layer to begin with at least they're making some efforts which is more than can be said less than a decade ago.
The way I see it, devs aren't obligated to support any system they don't want to. I really appreciate the ones that take the time to support Linux natively, or even by using an emulation layer because I realize they don't have to. If this makes more developers realize Linux is a viable ecosystem for them to make games for. Even if it's just through an emulation layer to begin with at least they're making some efforts which is more than can be said less than a decade ago.
Which would you see as more probable?
1) The ease of quality emulation leads to developers ceasing native linux support, resulting in lower quality linux gaming overall.
2) The ease of quality emulation leads more gamers to be willing to migrate to linux as their primary OS, thus helping linux come closer to being a first class deployment target, resulting in higher quality linux gaming overall.
Of course this isn't a dichotomy, but rather I think it's often unwise to look a gift horse in the mouth, especially when you're looking at hypotheticals.
1) The ease of quality emulation leads to developers ceasing native linux support, resulting in lower quality linux gaming overall.
2) The ease of quality emulation leads more gamers to be willing to migrate to linux as their primary OS, thus helping linux come closer to being a first class deployment target, resulting in higher quality linux gaming overall.
Of course this isn't a dichotomy, but rather I think it's often unwise to look a gift horse in the mouth, especially when you're looking at hypotheticals.
I think point 2 should be swapped for "ease of quality emulation means developers are willing to support linux through the emulation layer and can do so at reduced cost compared to porting"
He's right though. Linux gaming is a chicken and egg problem. Without enough users, the financial argument for making a Linux port is very weak. Without enough games, gamers will stay on Windows. At least if there's a reliable shim, the Linux gaming community might grow and become more relevant, fostering competition amongst game developers and hopefully incentivizing them to eventually doing native ports.
I'd rather see Microsoft and/or Valve shoot themselves in the foot, which they have come close to a couple times. As they took more control over what software is allowed to run on windows machines (or within steam's launcher) there was talk of content moderation, of limiting the most violent/adult games. Had that happened, linux could have been the place for 'adult' games. It might still happen. MS could take action against ROM emulators, bittorrent, client-side encryption, or any other form of software that would send the masses running to linux.
Prison Architect ran into this. It shows gang violence, drug use and executions, all of which are red flags for those who rate media. Funny story: Prison Architect actually received a notice that it was in violation of the Geneva convention. Papers Please, an indi great, might also have been shunned had Valve/MS adopted MPAA-like content moderation.
Prison Architect ran into this. It shows gang violence, drug use and executions, all of which are red flags for those who rate media. Funny story: Prison Architect actually received a notice that it was in violation of the Geneva convention. Papers Please, an indi great, might also have been shunned had Valve/MS adopted MPAA-like content moderation.
I think what we see more and more of is a focus on development frameworks that can target multiple platforms.
This already happening with frameworks like Unity.
As the plethora of capable devices increases, especially in the non-traditional gaming platforms like mobile and VR, the ability to support any device is going to be demanded by developers and will continue to improve.
The line between compiling for native and compiling for an emulation layer will shrink until there isn't really a difference. That's the only way for game developers to be able to keep up with new devices being released every other week.
The other benefit is keeping old catalogues around and playable into the far future, as long as we can keep beating DRM or always online mechanisms!
This already happening with frameworks like Unity.
As the plethora of capable devices increases, especially in the non-traditional gaming platforms like mobile and VR, the ability to support any device is going to be demanded by developers and will continue to improve.
The line between compiling for native and compiling for an emulation layer will shrink until there isn't really a difference. That's the only way for game developers to be able to keep up with new devices being released every other week.
The other benefit is keeping old catalogues around and playable into the far future, as long as we can keep beating DRM or always online mechanisms!
If dev teams want "native" (as per the definition you posted downstream [1]) linux ports, they will put in the effort just like before, except they now have another tool.
Maybe with this new tool, teams that wouldn't have considered putting any effort into porting their game will now change their mind.
Regardless, no one who cares about porting their game will ignore issues because it's not their problem.
[1] "Without expanding upon ever tiny definition, take "native" to mean a linux release developed, beta-tested, and supported by the original developer. Not something developed for windows and then expected to just run on linux boxes thanks to a compatability layer."
Maybe with this new tool, teams that wouldn't have considered putting any effort into porting their game will now change their mind.
Regardless, no one who cares about porting their game will ignore issues because it's not their problem.
[1] "Without expanding upon ever tiny definition, take "native" to mean a linux release developed, beta-tested, and supported by the original developer. Not something developed for windows and then expected to just run on linux boxes thanks to a compatability layer."
This isn't an entirely new idea. Eve Online had an officially supported Linux 'port' for a while until they dropped it because of low adoption rates. They 'ported to Linux' simply by licensing and bundling Cedega, and officially supporting the resulting package [0]. Not an unreasonable thing to do.
I wonder how much Vulkan will help here. I presume many devs will target Direct3D 12 instead, simply because of the Xbox One.
Somewhat related: slides from Valve about porting their Source engine from Windows to Linux [1].
[0] https://www.eveonline.com/article/an-update-on-linux-support [1] https://developer.nvidia.com/sites/default/files/akamai/game...
I wonder how much Vulkan will help here. I presume many devs will target Direct3D 12 instead, simply because of the Xbox One.
Somewhat related: slides from Valve about porting their Source engine from Windows to Linux [1].
[0] https://www.eveonline.com/article/an-update-on-linux-support [1] https://developer.nvidia.com/sites/default/files/akamai/game...
The nice thing about Linux and emulators is our reporting. It will be much easier to figure out what the issue is then most people think.
https://wiki.winehq.org/Bugs
https://wiki.winehq.org/Bugs
This is good for gaming on Linux!
Future prediction: Hackers reverse engineer Microsoft SQL server for Linux compatibility DLLs and adds better Wine support. Microsoft will eventually start selling a commercial Windows 10 compatibility layer for Linux. Reason Microsoft does not found main revenue through operating sales but of online cloud adoption and subscriptions. Microsoft of today is much more open source friendly than before.
https://en.wikipedia.org/wiki/Xenix https://en.wikipedia.org/wiki/Windows_Services_for_UNIX https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
Future prediction: Hackers reverse engineer Microsoft SQL server for Linux compatibility DLLs and adds better Wine support. Microsoft will eventually start selling a commercial Windows 10 compatibility layer for Linux. Reason Microsoft does not found main revenue through operating sales but of online cloud adoption and subscriptions. Microsoft of today is much more open source friendly than before.
https://en.wikipedia.org/wiki/Xenix https://en.wikipedia.org/wiki/Windows_Services_for_UNIX https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
> Hackers reverse engineer Microsoft SQL server for Linux compatibility DLLs and adds better Wine support. Microsoft will eventually start selling a commercial Windows 10 compatibility layer for Linux
I like the optimism but I honestly believe it's going to go the other way round.
Based on Microsoft s EEE strategy from the past, combined with the way they've pushed for SecureBoot on x86 and Arm and the (re-)rise of the WSL, I honestly expect it to get even more difficult in the future to boot a linux kernel on your own hardware.
Once all the usual suspects work properly under WSL I think more hardware lockdowns are going to come into place combined with phrases like "what do you need a kernel for? just boot windows kernel and use your linux userland and stop complaining!". The rise of GNU/Windows might well be coming...
I like the optimism but I honestly believe it's going to go the other way round.
Based on Microsoft s EEE strategy from the past, combined with the way they've pushed for SecureBoot on x86 and Arm and the (re-)rise of the WSL, I honestly expect it to get even more difficult in the future to boot a linux kernel on your own hardware.
Once all the usual suspects work properly under WSL I think more hardware lockdowns are going to come into place combined with phrases like "what do you need a kernel for? just boot windows kernel and use your linux userland and stop complaining!". The rise of GNU/Windows might well be coming...
I think Microsoft was right to push for Secure Boot / bootloader signing. The way they pushed for it was/is anti-competitive.
I don't think UEFI was the right horse to put money behind. It's a complicated hot mess and the most visible innovation has been to use UEFI identifiers for DRM within web browsers. Yay.
I don't think UEFI was the right horse to put money behind. It's a complicated hot mess and the most visible innovation has been to use UEFI identifiers for DRM within web browsers. Yay.
With intel ME next to it, it seems like asking for a metal door, with special key shapes the competition has a hard time to produce, but on a wall you know you can break with a hammer.
The current state of computing is less and less about being pro people, and more and more about pro big players.
The current state of computing is less and less about being pro people, and more and more about pro big players.
>I think Microsoft was right to push for Secure Boot / bootloader signing
Signing by whom? The OEM of course because giving the key to the user would be unacceptably user-friendly for microsoft.
>I don't think UEFI was the right horse to put money behind. It's a complicated hot mess and the most visible innovation has been to use UEFI identifiers for DRM within web browsers. Yay.
UEFI was done that way for a reason. Don't underestimate Microsoft's influence on other companies. Same thing with big web companies pushing "open" standards that only they have the manpower to comply with.
Signing by whom? The OEM of course because giving the key to the user would be unacceptably user-friendly for microsoft.
>I don't think UEFI was the right horse to put money behind. It's a complicated hot mess and the most visible innovation has been to use UEFI identifiers for DRM within web browsers. Yay.
UEFI was done that way for a reason. Don't underestimate Microsoft's influence on other companies. Same thing with big web companies pushing "open" standards that only they have the manpower to comply with.
That would be wonderful. If you're comparing kernel architectures, Linux kernel vs. NT is not much of a comparison. I will take NT kernel & gnu user space any day!
It's always nice to run a kernel designed by people who actually know what they're doing, and aren't doing it for the first time. Look into nt history, or how late Linux kernel started taking things like power management seriously. Hell, Linux kernel still insists on entirely living in nonpageable memory, most io is still synchronous, and there still is no stable driver API.
It's always nice to run a kernel designed by people who actually know what they're doing, and aren't doing it for the first time. Look into nt history, or how late Linux kernel started taking things like power management seriously. Hell, Linux kernel still insists on entirely living in nonpageable memory, most io is still synchronous, and there still is no stable driver API.
The linux kernel ain't perfect, but to say the NT kernel is superior is laughable imho. Take it with a grain of salt though as I am a greybeard sysadmin type who got so fed up with windows and MS that I moved completely to gnu/linux and haven't looked back.
Back on topic though, Skyrim normal edition installed and played just fine with proton for me on manjaro. This is nothing but good for us linux gamers.
Back on topic though, Skyrim normal edition installed and played just fine with proton for me on manjaro. This is nothing but good for us linux gamers.
NT sends CPU chasin' pointers between layers and layers of (filter) drivers in IRP madness.
But yeah, it's so great on NT I can set that 16 kB of IRQL passive level driver code pageable. Massive savings, and I'll only need to make sure I never ever run any of that code on IRQL dispatch or higher. If I mess up, the end user has a pretty blue screen to stare at.
I guess the impact of a pageable kernel was more important 10-20 years ago. Nowadays I rather allocate nonpageable memory just to avoid the headaches of not being able to actually use that memory at typical IRQLs a driver requires. For example DPCs run at dispatch IRQL, no access to pageable memory.
But yeah, it's so great on NT I can set that 16 kB of IRQL passive level driver code pageable. Massive savings, and I'll only need to make sure I never ever run any of that code on IRQL dispatch or higher. If I mess up, the end user has a pretty blue screen to stare at.
I guess the impact of a pageable kernel was more important 10-20 years ago. Nowadays I rather allocate nonpageable memory just to avoid the headaches of not being able to actually use that memory at typical IRQLs a driver requires. For example DPCs run at dispatch IRQL, no access to pageable memory.
Windows of today is nothing like what the original NT architecture was designed like.
Microsoft of today is much more open source friendly than before.
When it's in their interest to be so, don't expect them to start giving away their bread and butter.
When it's in their interest to be so, don't expect them to start giving away their bread and butter.
While I agree with you, it seems their bread and butter is shifting more towards their cloud-based services like Azure and Office 365.
That said, I don't see Windows ever going open source if only because of the huge amount of legacy bits and bobs borrowed from elsewhere that would be a nightmare to license.
That said, I don't see Windows ever going open source if only because of the huge amount of legacy bits and bobs borrowed from elsewhere that would be a nightmare to license.
The only thing I wish they'd open source (or provide Linux drivers for) is their Surface hardware drivers. I'm paying Microsoft more by buying the hardware than what they'd make selling me an OS license, let me install Linux on the damn thing without issues. If they did that I'd never bother buying any other type of laptop honestly. If I can run Ubuntu on a Surface with official Microsoft drivers I am one happy camper. I may very well keep Windows though for legacy .NET Framework stuff, but when doing .NET Core I prefer to just be on Linux and use either VS Code or Rider.
Just use win10 pro and use the Linux inside it... I've been using it and it is perfect. After you configure some good terminal to use that Linux and install your preferred text editor. It works well. You can access both file systems, run applications etc.
I do use WSL but it's just not the same at all. It's useful though but running Linux natively is another experience altogether. I can make my system as minimal as I want. There's the usefulness of WSL of not needing VM's which hog up all your ram as well just to run something under Linux.
Absolutely no way. I don't want anything that comes with windows, not just the tools available.
The only reason I still use Windows is Win32.
Explain?
Win32 is the original API for writing 32 (and 64) bit software to run on Windows. WINE functions by providing a compatibility layer for Win32 API calls. If WINE evolves to a state that it can run enough of the nominally Windows-only programs that people need, there's no more need for Windows.
Probably legacy software compatibility.
Why anyone would reverse engineer SQL Server for Linux is beyond me. It’s a good database...but it’s a trap. Once you’re on it, it’s nightmare to migrate off when you start hitting limitations. They go out of their way not to include features that make it possible to push data outside, so if your team is using even a single stored procedure for writing data you can’t just do it at the application level to bypass it.
Needs to be in less places, not more.
Needs to be in less places, not more.
They're only after the compatibility shims in its code to make it work on Linux.
Isn't the next version of SQL Server supposed to run in Linux?
Sql server 2017 already runs on Ubuntu 16.08, really well.
It runs through emulator, too [0].
[0]https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-se...
[0]https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-se...
Yes. Not sure what this prediction means in light of that.
Someone can use the Windows Server DLLs that ships with Microsoft SQL for Linux and use those DLLs to run Windows games better on Linux. An assumption is that Microsoft has shipped a Windows compatibility layer with Microsoft SQL Server for Linux.
Which they did, based on DrawBridge. It’s pretty interesting, basically it’s the NT kernel as a library OS which hosts native PE binaries. There are some white papers around.
This is amazing, thanks for the pointer!
Indeed, I'd always assumed that it was running natively.
WSL works really well actually, like magically well. I do all my web dev work on Windows instead of my aging Mac now.
I'll second that. I've had a near perfect experience using WSL for development. One of the best things Microsoft has added to Windows in many years.
I wish it was made more apparent. They made a big deal about "Bash for Windows", and that was it. I really had no idea it was literally an entire Linux distribution sitting inside Windows, with cross platform mounts and command line accessibility to either OS.
Hah funny you should say that.. A long time ago some friends and I debated whether Microsoft would eventually just turn Windows into a Window Manager that would sit on top of Linux/BSD/Darwin or something like that..
This was before Apple stopped caring about OSX/macOS though, so not sure this would still happen..
This was before Apple stopped caring about OSX/macOS though, so not sure this would still happen..
My only fear: devs will push for "just enough" Steam Play compatiblity instead of a proper Linux port. A lot of big AAA games got post-launch Linux release. These can disappear
I think I can live with devs targeting Wine on Linux instead of Linux directly, it saves them a lot of resources since most will be invested into Windows support.
And yes, maybe it means we get less Linux native, I don't mind either. If it works on Linux and is supported on Linux, even if it's just via Wine, that's all I want.
And yes, maybe it means we get less Linux native, I don't mind either. If it works on Linux and is supported on Linux, even if it's just via Wine, that's all I want.
Indeed. Modern software has plenty of layers of abstraction to begin with. One more isn't going to break the bank.
(I genuinely can't believe I'm posting this comment completely un-ironically, but here we are).
(I genuinely can't believe I'm posting this comment completely un-ironically, but here we are).
Most games will be running on an engine the studio bought, if not, it's usually one maintained by an in house team.
Which is, I suspect, the reason why some gamedevs are hesistant. For Linux they not only need the QA track and development resources but might have to redevelop some engine customizations for Linux or the engine might not even support Linux at all. They're two steps removed from the people who would be responsible for making the engine work on Linux at all.
Which is, I suspect, the reason why some gamedevs are hesistant. For Linux they not only need the QA track and development resources but might have to redevelop some engine customizations for Linux or the engine might not even support Linux at all. They're two steps removed from the people who would be responsible for making the engine work on Linux at all.
We're moving full-steam ahead to a client OS like qubes where every application is emulated on top of the original operating system it was developed for. We're pretty much already there for servers with containers.
While internally each application will be a security nightmare, one-level up it's a godsend!
I wouldn't be surprised if that qubes-like OS will have a kernel that runs WASM natively. Emulation galore turtles all the way down
While internally each application will be a security nightmare, one-level up it's a godsend!
I wouldn't be surprised if that qubes-like OS will have a kernel that runs WASM natively. Emulation galore turtles all the way down
I know more than a few people who prefer Linux but boot windows for gaming. The biggest reason they don't make a bigger effort to support Linux games is because there aren't enough options.
More emulation means more traction for Linux gaming. If windows can be dropped as a requirement for serious gaming, the Linux userbase will grow significantly, and this will help turn the tide.
More emulation means more traction for Linux gaming. If windows can be dropped as a requirement for serious gaming, the Linux userbase will grow significantly, and this will help turn the tide.
This may actually be better in the long run.
Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. If you're shipping Linux binaries, you really should be linking statically! Any shared libraries you need, like OpenGL, you should load manually with dlsym.
A windows binary targeting Wine will not stop working just because some shared system library has been updated.
Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. If you're shipping Linux binaries, you really should be linking statically! Any shared libraries you need, like OpenGL, you should load manually with dlsym.
A windows binary targeting Wine will not stop working just because some shared system library has been updated.
> Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected.
This is probably the biggest problem with Linux as a desktop, and the sad reality is that it will never ever be fixed because the community has an almost religious adherence to their completely broken platform model.
Maybe if Valve puts enough effort into WINE, the future of the open source desktop will be WINE on top of the Linux kernel? That'd be... tolerable.
This is probably the biggest problem with Linux as a desktop, and the sad reality is that it will never ever be fixed because the community has an almost religious adherence to their completely broken platform model.
Maybe if Valve puts enough effort into WINE, the future of the open source desktop will be WINE on top of the Linux kernel? That'd be... tolerable.
Well, now we have flatpak and snap to work around the "broken" software distribution models of most distros...
That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. There's really no excuse to not do things properly!
That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. There's really no excuse to not do things properly!
And before them we had GNUStep Application Bundles, ROX Filer AppDirs, and Klik (now AppImage). Flatpak and Snap do have some "advantages" over those from a Linux Desktop Community perspective though: They're incredibly over-engineered and they're the same idea implemented twice.
> That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems.
Only on Linux, which is kinda my point. Other platforms are actually, you know, platforms.
> That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems.
Only on Linux, which is kinda my point. Other platforms are actually, you know, platforms.
Linux implements several platforms. The issue is that the API is stable at the _source_ level, not the binary level. I guess the ideal for Linux would be for these games to be open source, but of course that will not (should not?) happen for obvious reasons.
The obvious solution is, distribute the source code and build on end user's environment.
Distributing the source code doesn't necessarily mean free software. Since those free software haters(idiots if you ask me), has no problem distributing game assets and compiled binary to the user, why is the source code exception?
If you are idiot enough to want the source code to be secret, just minify and uglify the source code. Uglified source code is as readable as compiled binary.
Distributing the source code doesn't necessarily mean free software. Since those free software haters(idiots if you ask me), has no problem distributing game assets and compiled binary to the user, why is the source code exception?
If you are idiot enough to want the source code to be secret, just minify and uglify the source code. Uglified source code is as readable as compiled binary.
I've never heard of these. Can you give more info?
Flatpak and Snap are new package formats, which allow bundling software with all the libraries that it needs.
Advantage is that developers can package exactly those versions of the libraries that they tested with and know to be working.
Disadvantage is that if there's a security problem or bug in one of those libraries, you're dependent on the developer to release a new version of the Flatpak or Snap package.
Another disadvantage is that libraries can't be shared between applications, which increases hard drive and RAM usage.
A second important aspect of Flatpak and Snap packages, which is however not relevant to the discussion, is that the execution of the packaged applications is done in a sandboxed environment.
Advantage is that developers can package exactly those versions of the libraries that they tested with and know to be working.
Disadvantage is that if there's a security problem or bug in one of those libraries, you're dependent on the developer to release a new version of the Flatpak or Snap package.
Another disadvantage is that libraries can't be shared between applications, which increases hard drive and RAM usage.
A second important aspect of Flatpak and Snap packages, which is however not relevant to the discussion, is that the execution of the packaged applications is done in a sandboxed environment.
Are they exactly as portable as a statically linked binary, or more? (I vaguely recall static binaries still depending on kernel versions, or something like that)
There's different levels of static linking.
0) Application links to shared .so files in /usr/lib like libpcre.so. This is ordinary dynamic linking.
1) Application statically links all normal libraries like zlib and pcre, but still dynamically links to runtime systems like libc.so. I'll call this ordinary static linking. You can't "patch" a vulnerability in zlib without recompiling and redistributing, but on the other hand a zlib upgrade can't break your app either.
2) Application literally statically links everything (e.g. using musl instead of glibc). At this point the only dependency is the kernel you're running on. You need:
* obviously the kernel and architecture have to match. Can't run a 64-bit program on a 32-bit system without recompilation. Can't run a program compiled for linux on bsd.
* the kernel has to support whatever syscalls your application is using. If you're not using any fancy new functionality, you can get away with running on truly ancient kernels (e.g. 2.x linux)
* the kernel ABI must not break in the future. E.g. if linux changed the order of parameters to the open(2) call, that would be a breaking ABI change. Kernel devs are extremely careful to not do this, so I wouldn't worry about it.
The new packaging formats like Flatpak are based on containers. Your app thinks that it's using the "system" libpcre.so, but in actuality it's just being served the libpcre.so inside the container's filesystem (linked by the ld inside the container's filesystem, using the glibc inside the container's filesystem, and so on). So basically the same high level pro/cons as #2 above, but easier for users and developers.
0) Application links to shared .so files in /usr/lib like libpcre.so. This is ordinary dynamic linking.
1) Application statically links all normal libraries like zlib and pcre, but still dynamically links to runtime systems like libc.so. I'll call this ordinary static linking. You can't "patch" a vulnerability in zlib without recompiling and redistributing, but on the other hand a zlib upgrade can't break your app either.
2) Application literally statically links everything (e.g. using musl instead of glibc). At this point the only dependency is the kernel you're running on. You need:
* obviously the kernel and architecture have to match. Can't run a 64-bit program on a 32-bit system without recompilation. Can't run a program compiled for linux on bsd.
* the kernel has to support whatever syscalls your application is using. If you're not using any fancy new functionality, you can get away with running on truly ancient kernels (e.g. 2.x linux)
* the kernel ABI must not break in the future. E.g. if linux changed the order of parameters to the open(2) call, that would be a breaking ABI change. Kernel devs are extremely careful to not do this, so I wouldn't worry about it.
The new packaging formats like Flatpak are based on containers. Your app thinks that it's using the "system" libpcre.so, but in actuality it's just being served the libpcre.so inside the container's filesystem (linked by the ld inside the container's filesystem, using the glibc inside the container's filesystem, and so on). So basically the same high level pro/cons as #2 above, but easier for users and developers.
I'm not super familiar with Flatpak and Snap, but I don't think so. They each require a runtime and use special fixed directories.
AppImage requires no runtime (or more accurately, it is part of the package) and is almost as portable as a statically linked binary, largely because it is (practically) a statically linked binary.
> I vaguely recall static binaries still depending on kernel versions, or something like that
This has to do with glibc. If you don't use glibc you don't really have to worry about it.
AppImage requires no runtime (or more accurately, it is part of the package) and is almost as portable as a statically linked binary, largely because it is (practically) a statically linked binary.
> I vaguely recall static binaries still depending on kernel versions, or something like that
This has to do with glibc. If you don't use glibc you don't really have to worry about it.
tl;dr: Both are running applications with the exact versions of dependencies inside a separated environment (read as mount namespaces, there could be mounted directories from main file hierarchy).
> completely broken platform model
Hardly.
It works extremely well for Linux distribution maintainers, and for the FOSS projects that work with this model in mind. Within the FOSS community, the platform model is excellent.
It doesn't work so well for proprietary application developers, who should just be using static libs because of this.
Hardly.
It works extremely well for Linux distribution maintainers, and for the FOSS projects that work with this model in mind. Within the FOSS community, the platform model is excellent.
It doesn't work so well for proprietary application developers, who should just be using static libs because of this.
More likely, this will enable existing titles to run on Linux, making it easier to sell Linux machines like Valve's Steam boxes. Meanwhile, Valve can incentivize native ports on their platforms through many means, so I don't think an OS/2 situation is likely. Also, having a good DirectX 12 implementation on top of Vulkan will likely be useful the same way that Vulkan on top of Metal is useful for macOS ports.
Of course... it's still a long and difficult road for Valve here, given how well emulation will need to work to accomplish this.
Of course... it's still a long and difficult road for Valve here, given how well emulation will need to work to accomplish this.
Not to mention that it acts as a compatibility layer for older games that don't run on Windows 10 and others that will stop working as they remove more and more legacy code/features.
Some say there are games that have noticeable stutters or bottlenecks on Windows that doesn't share the same issues on Wine.
Some say there are games that have noticeable stutters or bottlenecks on Windows that doesn't share the same issues on Wine.
This would be nice, but I won't hold my breath too much: Valve is invested in current technologies like DX11 and DX12 emulation, whereas it'd be nice to see better emulation of D3D8/9 and DDraw if possible.
Things will only get better from now on (or as long as the money keeps flowing).
https://github.com/disks86/VK9
https://github.com/doitsujin/dxvk/issues/551
https://github.com/doitsujin/dxvk/pull/541
https://github.com/disks86/VK9
https://github.com/doitsujin/dxvk/issues/551
https://github.com/doitsujin/dxvk/pull/541
Wow... Nice. I had always dreamed of commercially-supported Wine Direct3D improvements, and there's hardly a better company to invest than Valve. Valve definitely is willing to make longer term plays, especially looking at how long they've been working with Linux in general. Hope to see older titles improve as work goes on.
ts-ddraw and cnc-ddraw provide a decent base for certain ddraw games C&C95, Red Alert, Warcraft 2, C&C Tiberian Sun, and Red Alert 2.
This is Warcraft 2 with cnc-ddraw using xbrz: https://i.imgur.com/sG1DC23.png
https://github.com/CnCNet/cnc-ddraw
https://github.com/CnCNet/ts-ddraw
Use case https://www.reddit.com/r/linux_gaming/comments/97l5bk/cc_tib...
https://github.com/CnCNet/cnc-ddraw
https://github.com/CnCNet/ts-ddraw
Use case https://www.reddit.com/r/linux_gaming/comments/97l5bk/cc_tib...
In the original announcement they say since 2016 they have been working with CodeWeavers on areas including "Many wined3d performance and functionality fixes for Direct3D 9 and Direct3D 11"
https://steamcommunity.com/games/221410/announcements/detail...
https://steamcommunity.com/games/221410/announcements/detail...
Directx9 workf fine in Wine already, the problems were with Directx11, there are some obscure games that are not working on Wine, some games need specific fixes since they were working on Windows by mistake.
I could not play Oblivion on Windows10 but worked on Wine for me.
I could not play Oblivion on Windows10 but worked on Wine for me.
Proton is still Wine at its core. It's been handling that stuff for ages.
and if at some point linux becomes good enough, companies might start targeting dxvk directly instead of wine. that alone would remove a lot of friction to proper ports.
Even Steam itself is "just enough." Off the top of my head, the Steam Linux client:
* Ignores flags (so `steam --help` for instance just starts Steam the same way `steam` does)
* Ignores signals (including SIGTERM, I believe)
* Screws up my tiling window manager sometimes, so it probably ignores EWMH
I personally think Valve needs to just separate the core Steam functionality into some backend and allow users to write their own frontends.
===========
And now for an unrelated "Valve/Linux" rant while I'm here: Half-Life: Opposing Force has been unbeatable on Linux since its release. The final boss's death animation plays too quickly and the trigger to change to the next map never occurs. There's been an issue open on the ValveSoftware/halflife GitHub repo about this since 2013. And the real kicker? Someone (not a Valve employee) actually went through the source code and determined the cause of the problem[0]. It still hasn't been fixed.
===========
Screw it, I'll give you one more. Last time I checked, it was impossible to get Half-Life Dedicated Server running through steamcmd[1][2], because the necessary files never finished downloading. When I was trying to get this working, I eventually found a GitHub repo containing modified versions of some files that you could use to make steamcmd actually download everything. I was unable to find this repo again while writing this comment (but I didn't put that much effort into it).
</rant>
0. https://github.com/ValveSoftware/halflife/issues/917#issueco...
1. https://github.com/ValveSoftware/halflife/issues/928
2. https://steamcommunity.com/discussions/forum/14/129181688050...
* Ignores flags (so `steam --help` for instance just starts Steam the same way `steam` does)
* Ignores signals (including SIGTERM, I believe)
* Screws up my tiling window manager sometimes, so it probably ignores EWMH
I personally think Valve needs to just separate the core Steam functionality into some backend and allow users to write their own frontends.
===========
And now for an unrelated "Valve/Linux" rant while I'm here: Half-Life: Opposing Force has been unbeatable on Linux since its release. The final boss's death animation plays too quickly and the trigger to change to the next map never occurs. There's been an issue open on the ValveSoftware/halflife GitHub repo about this since 2013. And the real kicker? Someone (not a Valve employee) actually went through the source code and determined the cause of the problem[0]. It still hasn't been fixed.
===========
Screw it, I'll give you one more. Last time I checked, it was impossible to get Half-Life Dedicated Server running through steamcmd[1][2], because the necessary files never finished downloading. When I was trying to get this working, I eventually found a GitHub repo containing modified versions of some files that you could use to make steamcmd actually download everything. I was unable to find this repo again while writing this comment (but I didn't put that much effort into it).
</rant>
0. https://github.com/ValveSoftware/halflife/issues/917#issueco...
1. https://github.com/ValveSoftware/halflife/issues/928
2. https://steamcommunity.com/discussions/forum/14/129181688050...
There's an open source version of the Half Life engine called Xash3d which is feature complete:
https://github.com/FWGS/xash3d
It's also got an excellent Android port:
https://www.moddb.com/games/xash3d-android
https://github.com/FWGS/xash3d
It's also got an excellent Android port:
https://www.moddb.com/games/xash3d-android
Thanks for the heads up on the OpFor issue - I just started playing through the original HL games again.
Do we care how the Linux compatibility is achieved? If the end result is the game is available on Linux, stable and performant why should I give a damn that it uses Wine internally any more than whether is uses Unity or python or whatever?
I suspect you're right in the short term, but in the long term it will push more users to adopt Linux and maybe eventually devs will pay more attention.
Most (if not all, now) of the major engines (Unreal, Unity, ???) export native binaries for Windows, Mac, and Linux. This seems more for getting legacy titles included.
Even without emulation it is impressive how much of Steam's library is available on Linux.
Even without emulation it is impressive how much of Steam's library is available on Linux.
This already happens. Gnomoria had just bolted on Mono. And there were many games that simply used winelib.
Gnomoria running Mono? It's not a .NET project but a Java one, might you be confusing it with Terraria or something?
If it means devs go back and tweak the one or two minor issues that prevent their game from working on Wine then I can't complain that much.
In case anyone else is wondering, this spreadsheet is posted as one of the github issues and compiles people's tests of different games:
https://docs.google.com/spreadsheets/d/1DcZZQ4HL_Ol969UbXJmF...
https://docs.google.com/spreadsheets/d/1DcZZQ4HL_Ol969UbXJmF...
> Machinarium --> Anything else notable? --> Still cute ass heck
Is this a Freudian slip from one of those robosexuals?
Is this a Freudian slip from one of those robosexuals?
This is the corresponding github issue, open since 2012: https://github.com/ValveSoftware/steam-for-linux/issues/74 :)
At some point during the beta of the Steam client for Linux, there was a bug in that you could install Windows games on Linux. I had a binfmt_misc setup at the time, which allowed me to run Windows executables directly through Wine as if they were ordinary ELF binaries. I don't remember exactly what happened when I tried running one, I think it failed when the Steam copy protection kicked in, but I always wondered if they couldn't make this work.
At some point during the beta of the Steam client for Linux, there was a bug in that you could install Windows games on Linux. I had a binfmt_misc setup at the time, which allowed me to run Windows executables directly through Wine as if they were ordinary ELF binaries. I don't remember exactly what happened when I tried running one, I think it failed when the Steam copy protection kicked in, but I always wondered if they couldn't make this work.
> Users playing through Steam Play experiencing Linux-specific issues should be directed to Steam for support
I wonder how they'll handle user reviews. Maybe performance won't be an issue, I know some games run even faster than on Windows, but bugs that you don't know are Proton specific could lead to bad reviews.
I wonder how they'll handle user reviews. Maybe performance won't be an issue, I know some games run even faster than on Windows, but bugs that you don't know are Proton specific could lead to bad reviews.
This could be intentional, as it incentivizes developers to support the Proton version, which makes native Linux support a much smaller leap.
Excited as I am about a big player pushing Linux, we mustn't forget that the intent is almost certainly just to chip away at Windows and the threat it poses to Valve's own monopoly (as a PC game distributor).
Excited as I am about a big player pushing Linux, we mustn't forget that the intent is almost certainly just to chip away at Windows and the threat it poses to Valve's own monopoly (as a PC game distributor).
A good deed done for selfish reasons is still a good deed done. Frankly I'm just happy to see Linux gaming getting any kind of attention as it's the only reason I still dual boot Windows.
The more charitable interpretation is that Windows as it‘s currently handled is an unpredictable mess that you don’t want to be dependend on.
I think the intent is just to have an out for when Microsoft inevitably kills off the Windows personal desktop, either intentionally in favor of a subscription-based cloud service or through simply making it so crap that extremely desperate people turn to Linux instead.
Valve's behavior suggests that they've never really sought a monopolistic position. Vive was open to everyone, there's no exclusivity agreements with their marketplace, etc. But Steam requires a platform to sell games for, so making sure there's some kind of alternative is in their best interest.
Valve's behavior suggests that they've never really sought a monopolistic position. Vive was open to everyone, there's no exclusivity agreements with their marketplace, etc. But Steam requires a platform to sell games for, so making sure there's some kind of alternative is in their best interest.
Steam reviews have recently started including "caveat" titles above the reviews themselves, like "Game received for free" or "Presale purchase". I wouldn't be surprised if Valve next added a "Linux version review" caveat.
From a user POV though, I guess proton is an improvement. It means there is a specific windows-like platform called "Proton" that might just about earn a spot in in someone's test matrix.
In that sense, the more bad reviews the better!
In that sense, the more bad reviews the better!
As I said in another thread:
Congrats!
And big thanks to developers and Valve who funded dxvk, vkd3d, esync and other Wine as well as Mesa work, while contributing everything in FOSS fashion. This benefits not just Steam users but all Linux gamers.
Congrats!
And big thanks to developers and Valve who funded dxvk, vkd3d, esync and other Wine as well as Mesa work, while contributing everything in FOSS fashion. This benefits not just Steam users but all Linux gamers.
Valve really needs to roll out a 64bit client though. I always have problems just installing the client because of the 32bit architecture.
Use your package manager.
I've had a lot of bad experiences installing Steam from a package manager and having problems with either the Steam client itself or games crashing because they can't find 32-bit OpenGL libraries. I haven't had such issues that I can remember the last few times I've installed steam, but "use your package manager" isn't (or hasn't always been) the complete answer.
It's gotten better recently on Ubuntu and derivatives. "Use your package manager" actually works and installs all the correct 32 bit compatibility libraries. "sudo apt install steam" really is all you need now.
That, combined with improved Wine compatibility, means that a lot of Windows games already run great on Linux, though with the obligatory performance hit due to driver differences and such. Hopefully once Vulkan support matures on both platforms we'll start seeing parity, especially with games that have a native Linux port or were Linux-first.
That, combined with improved Wine compatibility, means that a lot of Windows games already run great on Linux, though with the obligatory performance hit due to driver differences and such. Hopefully once Vulkan support matures on both platforms we'll start seeing parity, especially with games that have a native Linux port or were Linux-first.
"apt install steam" is not enough on amd64 Debian installations[1] which are much more common.
[1]https://wiki.debian.org/Steam#A64-bit_systems_.28amd64.29
[1]https://wiki.debian.org/Steam#A64-bit_systems_.28amd64.29
Correct, which is why I said "Ubuntu and derivatives". Debian is upstream of Ubuntu, not downstream.
The "fun" part is that SteamOS is (was?) a derivative of Debian.
Yeah multiarch was an annoyance. Not sure why it's nontrivial on their side.
Flatpak to the rescue!
I personally hope for Snaps or similar. Games could really benefit from containment. There is no reason for Counter Strike mods to have access to your World of Warcraft credentials, or your web browser or email client have access to them for that matter.
https://flathub.org/apps/details/com.valvesoftware.Steam
The only issue is that I can't get Hardware Accelerated Decoding to work in Steam Streaming. I believe that's because I don't have the 32bit libraries and associated dependencies for doing it installed and that's the whole point of me going the flatpak route!
Other than that, works beautifully. Didn't go flatpak for Spotify though.
The only issue is that I can't get Hardware Accelerated Decoding to work in Steam Streaming. I believe that's because I don't have the 32bit libraries and associated dependencies for doing it installed and that's the whole point of me going the flatpak route!
Other than that, works beautifully. Didn't go flatpak for Spotify though.
How so?
It's 2018 and Linux still has issues with this? It's a complete non-issue on Windows. One wonders if you can really blame Valve for the Linux desktop community not being able to accomplish such a simple thing as running 32-bit applications along side 64-bit ones.
It's not 2018 and Linux still has issues with this, rather it's 2018 and Linux is starting to have real issues with this.
Windows is the only desktop OS where 32-bit is still commonly used. On Linux, you nowadays generally don't have any 32-bit applications installed. Many Linux distributions don't offer 32-bit support anymore at all, because you'll have a seriously hard time finding hardware that doesn't support 64-bit.
With Steam however at the moment still only being available as 32-bit, you need 32-bit versions of the libraries that Steam uses. Distributions not hosting 32-bit libraries anymore, means you need to get these libraries in a different way.
Many distributions now actually offer you to install a Steam installer, which then gets the necessary 32-bit libraries from elsewhere.
You can also install Steam through a new package format, called "Flatpak", which includes all the necessary libraries directly in the package.
But these are all new workarounds and may still have problems. Flatpak in fact has only turned 1.0 a few days ago.
Windows is the only desktop OS where 32-bit is still commonly used. On Linux, you nowadays generally don't have any 32-bit applications installed. Many Linux distributions don't offer 32-bit support anymore at all, because you'll have a seriously hard time finding hardware that doesn't support 64-bit.
With Steam however at the moment still only being available as 32-bit, you need 32-bit versions of the libraries that Steam uses. Distributions not hosting 32-bit libraries anymore, means you need to get these libraries in a different way.
Many distributions now actually offer you to install a Steam installer, which then gets the necessary 32-bit libraries from elsewhere.
You can also install Steam through a new package format, called "Flatpak", which includes all the necessary libraries directly in the package.
But these are all new workarounds and may still have problems. Flatpak in fact has only turned 1.0 a few days ago.
> With Steam however at the moment still only being available as 32-bit, you need 32-bit versions of the libraries that Steam uses. Distributions not hosting 32-bit libraries anymore, means you need to get these libraries in a different way.
Which are those distributions? It's true that most don't offer regular applications, but at least for my distro (Arch), there is still a 32-bit repo for 64-bit systems, with various system libraries and applications that are only available as 32-bit (besides Steam, this includes Wine and various emulators for old consoles): https://www.archlinux.org/packages/?repo=Multilib
Which are those distributions? It's true that most don't offer regular applications, but at least for my distro (Arch), there is still a 32-bit repo for 64-bit systems, with various system libraries and applications that are only available as 32-bit (besides Steam, this includes Wine and various emulators for old consoles): https://www.archlinux.org/packages/?repo=Multilib
I was thinking of openSUSE and Ubuntu, but you're right that openSUSE still has 32-bit libraries around.
In the openSUSE Leap 15.0 standard repos, there's 6554 packages named "lib..." and 1368 named "lib...32bit", so roughly 20% of libraries have a 32 bit version still, which obviously could well be enough to contain all the libraries needed for Steam. (In total, there's 36237 packages, of which 1804 are 32 bit.)
With Ubuntu, I'm not entirely sure, as I don't run it, I've just heard that Lubuntu is having problems, because they would still like to support 32-bit, but with other Ubuntu flavors not anymore being released with 32-bit support, they're having trouble keeping it up. Might just be proper testing of the 32-bit libraries, though.
Well, and then there is obviously more niche distributions, which never bothered with 32-bit. Chakra Linux, for example, is so niche, they don't even provide any GTK applications in their main repository, and I think no 32-bit packages either. They do have a community repository, which has more stuff in it, but even there, I can only find around 20 packages with 32-bit support.
In the openSUSE Leap 15.0 standard repos, there's 6554 packages named "lib..." and 1368 named "lib...32bit", so roughly 20% of libraries have a 32 bit version still, which obviously could well be enough to contain all the libraries needed for Steam. (In total, there's 36237 packages, of which 1804 are 32 bit.)
With Ubuntu, I'm not entirely sure, as I don't run it, I've just heard that Lubuntu is having problems, because they would still like to support 32-bit, but with other Ubuntu flavors not anymore being released with 32-bit support, they're having trouble keeping it up. Might just be proper testing of the 32-bit libraries, though.
Well, and then there is obviously more niche distributions, which never bothered with 32-bit. Chakra Linux, for example, is so niche, they don't even provide any GTK applications in their main repository, and I think no 32-bit packages either. They do have a community repository, which has more stuff in it, but even there, I can only find around 20 packages with 32-bit support.
What are the issues exactly? 32 bit libraries are not installed by deafult in most distros because the vast majority of the software has been ported to 64 bits decades ago.
Don't look at me, it's parent who has an issue:
> I always have problems just installing the client because of the 32bit architecture
This is trivial and completely not a problem on Windows. Why is it a problem on Linux? Because there's no thought given to compatibility, it is just assumed that the only software anyone cares about will be compiled from source against the hard-coded library names and paths of any specific distro.
> I always have problems just installing the client because of the 32bit architecture
This is trivial and completely not a problem on Windows. Why is it a problem on Linux? Because there's no thought given to compatibility, it is just assumed that the only software anyone cares about will be compiled from source against the hard-coded library names and paths of any specific distro.
Not sure Windows is a good example there. The "thought given to compatibility" under Windows is typically "each application ships all the runtime redistributables, DirectX packages, ... it could need, because there's no standard for which ones are available", which solves the problem, but isn't through superior flexibility over hard-coded dependencies.
But there is quite a lot of thought given to keeping applications that ran on previous Windows versions running on newer ones, without recompilation. And bundling all the non-system-provided dependencies with the application actually is a ton more flexible. In many instances, you can put the application's folder on a thumb drive and run it from there on a different computer. Try that with Linux applications without jumping through a ton of hoops, the first of which is "how do I know which files belong to this application, since they're spread all over the file hierarchy and mixed in with everything else?".
I don't know why you're trolling all over this thread, but this makes it sound like you don't know what you're talking about.
Why do you think you can't ship your non-system-provided dependencies on Linux? This is the common complaint about Linux, that you have to bundle a bunch of dependencies if you want it to run everywhere. You can also ship a single directory containing your application that is runnable wherever you drop it.
> "how do I know which files belong to this application, since they're spread all over the file hierarchy and mixed in with everything else?"
Just an FYI, ldd <binary> will tell you the libraries you depend on, but if you're shipping all non-system-provided dependencies, there shouldn't be anything that points outside of your directory other than libc.
Why do you think you can't ship your non-system-provided dependencies on Linux? This is the common complaint about Linux, that you have to bundle a bunch of dependencies if you want it to run everywhere. You can also ship a single directory containing your application that is runnable wherever you drop it.
> "how do I know which files belong to this application, since they're spread all over the file hierarchy and mixed in with everything else?"
Just an FYI, ldd <binary> will tell you the libraries you depend on, but if you're shipping all non-system-provided dependencies, there shouldn't be anything that points outside of your directory other than libc.
> Why do you think you can't ship your non-system-provided dependencies on Linux?
I don't think that. It's just that:
> but if you're shipping all non-system-provided dependencies, there shouldn't be anything that points outside of your directory other than libc
In other words you have to ship most of what other operating systems consider to be part of the base system, because Linux doesn't provide a standardized basesystem at all. Hell, even depending on libc can be a problem, NixOS even manages to break AppImage because of how ld.so works, and to top it all off glibc abhors static linking.
I don't think that. It's just that:
> but if you're shipping all non-system-provided dependencies, there shouldn't be anything that points outside of your directory other than libc
In other words you have to ship most of what other operating systems consider to be part of the base system, because Linux doesn't provide a standardized basesystem at all. Hell, even depending on libc can be a problem, NixOS even manages to break AppImage because of how ld.so works, and to top it all off glibc abhors static linking.
It's not a problem on linux whatsoever. On traditional package managers it just required some thought from the maintainer. Newer ones like flatpak make it even simpler.
Windows on the other hand just lets you bundle everything with your application including libraries that might have vulnerabilities without any form of sandboxing and no formal mechanism under which they can be updated. On linux on the other hand you can rely on the distro to ship patched versions of system libraries while the application itself is much more limited in regards of permissions.
Windows on the other hand just lets you bundle everything with your application including libraries that might have vulnerabilities without any form of sandboxing and no formal mechanism under which they can be updated. On linux on the other hand you can rely on the distro to ship patched versions of system libraries while the application itself is much more limited in regards of permissions.
What's the driving force behind this? Is it so that Valve won't have to be dependent on microsoft or a "windows tax" for their gaming boxes? Or is it that microsoft simply wouldn't agree to license windows to them because they are already pushing xboxes? Or is it something else?
Microsoft is trying to make Windows app distribution more like iOS. As a third party software store for Windows, Steam is prohibited from being in the Windows Store or running at all on Windows S. This is a direct attack on Valve, since Windows game sales make up the vast majority of their revenue.
Although the Windows Store and Windows S have not been successful so far, Valve is still hedging their bets and trying to reduce their dependency on Windows and DirectX by promoting Linux and Vulkan.
Although the Windows Store and Windows S have not been successful so far, Valve is still hedging their bets and trying to reduce their dependency on Windows and DirectX by promoting Linux and Vulkan.
First Microsoft has to get every app on the windows store, then they have to get people to start using it and then they cut off external software sources or make it hard to do like requiring power shell to enable.
Its obvious this is the long term plan for MS. Apple has already shown people will buy locked down systems.
Its obvious this is the long term plan for MS. Apple has already shown people will buy locked down systems.
They don't need to do any of that. Chromebooks became a thing without having a lot of software available on the platform.
Microsoft already followed the footsteps with Windows 10 S. And they're the first major OS that's taking advantage of Progressive Web Apps and adding them to their store, removing the need to build Windows-only software completely while still offering "native" experience: https://developer.microsoft.com/en-us/windows/pwa
I personally think that Microsoft learned their lessons with Windows 10 Mobile and that they're going to excel at being a competitor to Chromebooks.
Microsoft already followed the footsteps with Windows 10 S. And they're the first major OS that's taking advantage of Progressive Web Apps and adding them to their store, removing the need to build Windows-only software completely while still offering "native" experience: https://developer.microsoft.com/en-us/windows/pwa
I personally think that Microsoft learned their lessons with Windows 10 Mobile and that they're going to excel at being a competitor to Chromebooks.
It's not obvious at all. They haven't cracked down on external software sources and I doubt they are stupid enough to believe they could get away with such a thing if they tried. It would be a dealbreaker for business users in particular.
I think the more plausible explanation is that Microsoft wrote the store because users expect to have one on mobile devices (i.e. Surface) and Windows 8 was an attempt at tablet-PC convergence.
I think the more plausible explanation is that Microsoft wrote the store because users expect to have one on mobile devices (i.e. Surface) and Windows 8 was an attempt at tablet-PC convergence.
The original reasoning for Valve's Linux push was the shock from how terrible Windows 8 was and for the most part still is.
At that point, they realised that if Microsoft is being stupid, there's nothing they can do against it. Almost their entire market is in the hand of Microsoft.
And yeah, it certainly didn't help that Windows 8 featured the Windows Store, therefore officially competed with Steam, and included a new application API (Metro Apps, now known as UWP), which I think back then was still exclusive to the Windows Store. Nowadays you technically can sideload them, but if we look at Android, that's still not much comfort.
At that point, they realised that if Microsoft is being stupid, there's nothing they can do against it. Almost their entire market is in the hand of Microsoft.
And yeah, it certainly didn't help that Windows 8 featured the Windows Store, therefore officially competed with Steam, and included a new application API (Metro Apps, now known as UWP), which I think back then was still exclusive to the Windows Store. Nowadays you technically can sideload them, but if we look at Android, that's still not much comfort.
Even if this project never completely replaces Windows, it's existence ensure Valve gets favorable negotiating terms with Microsoft.
Of course, I'd really really love if the gap closed enough that Windows became completely optional for gaming (and now, VR for me). My Windows 10 upgrade recently was purely to run my HTC Vive with DX12 - there's nothing else on that partition.
Of course, I'd really really love if the gap closed enough that Windows became completely optional for gaming (and now, VR for me). My Windows 10 upgrade recently was purely to run my HTC Vive with DX12 - there's nothing else on that partition.
Microsoft doesn't withold OEM licenses from competitors. That wouldn't make sense for a number of reasons.
1. Microsoft doesn't license xbox software, so in that regard a Valve Box isn't a direct competitor.
2. Windows and Xbox (Entertainment) are separate business units, with different revenue targets.
3. Xbox is far from the market leader in the current console generation, and hampering Windows sales to boost Xbox won't make up the difference.
4. There doesn't exist a relationship that can't be forged by increasing the how much you pay. Said plainly: if you're willing to pay, Microsoft will do business with you (governments and legalities aside).
To the original question, why Valve does anything is a mystery. Speculating: This is laying foundations for streaming games as a service. Linux is their target platform for the game servers.
I don't believe this is about top-line revenue, as PC Master Race has overwhelmingly chosen Windows as it's OS, and it's not going to change.
Edit to Add:
Actually as I think about this more, the central motivation is even more simplistic: a group of valve employees wanted to make more games compatible on Linux. Their entire driving force is doing stuff they find interesting, as long as it benefits the customer. There exists Valve customers who can't play games, because they're not available on Linux. Thus, Valve is addressing it.
Valve has so much capital resources, they're not motivated at all by financial reasons.
1. Microsoft doesn't license xbox software, so in that regard a Valve Box isn't a direct competitor.
2. Windows and Xbox (Entertainment) are separate business units, with different revenue targets.
3. Xbox is far from the market leader in the current console generation, and hampering Windows sales to boost Xbox won't make up the difference.
4. There doesn't exist a relationship that can't be forged by increasing the how much you pay. Said plainly: if you're willing to pay, Microsoft will do business with you (governments and legalities aside).
To the original question, why Valve does anything is a mystery. Speculating: This is laying foundations for streaming games as a service. Linux is their target platform for the game servers.
I don't believe this is about top-line revenue, as PC Master Race has overwhelmingly chosen Windows as it's OS, and it's not going to change.
Edit to Add:
Actually as I think about this more, the central motivation is even more simplistic: a group of valve employees wanted to make more games compatible on Linux. Their entire driving force is doing stuff they find interesting, as long as it benefits the customer. There exists Valve customers who can't play games, because they're not available on Linux. Thus, Valve is addressing it.
Valve has so much capital resources, they're not motivated at all by financial reasons.
I suppose its because Microsoft is now (since Windows 8) in the `app/game store` business on Windows.
My guess too - and they are also in the windows-for-couch-gaming space since forever (with xbox). But this project has to be very expensive for valve, so I'm wondering if it's not more expensive than just selling boxes with windows on it to play all these games that are mostly windows anyway? And that raises the question of whether that was ever a possibility
This would be like building a Facebook app or twitter client; essentially at the mercy of the platform owner. MS is already competing with Valve - it would be incredibly stupid on Valve’s part to be dependent on MS
It would be undesireable at least, and possibly come at great cost. The question is perhaps - is that cost still not smaller than trying to make future games work with wine (something that has traditionally not been very successful)?
If the ms App Store is successful, then it is the end of valve as we know it today, so it makes sense for them to invest what is a relatively small amount (10 people at $150k/year for two years is just $2m - do they have that many people on it?)
The majority of the cost is actually borne by the studios/developers - compatibility testing and fixes - for little pay now (though possibly nontrivial one in the future). So it doubly makes sense for Valve
The majority of the cost is actually borne by the studios/developers - compatibility testing and fixes - for little pay now (though possibly nontrivial one in the future). So it doubly makes sense for Valve
Looking at other game publishers, Doom Eternal/Fallout 76 might not be on Steam and the newest CoD: Black Ops 4 will only be on Battle.net. GoG is DRM free and getting a lot of indie dev games.
Valve needs to sell more games, and this is the easiest way to do it. They haven't completely given up on Steam Machines/OS, so better Steam play options just reinforces that freedom-from-MS initiative.
I think it makes sense in a couple of ways, especially considering how good Wine was getting, and the availability of good GPU drivers on Linux.
Valve needs to sell more games, and this is the easiest way to do it. They haven't completely given up on Steam Machines/OS, so better Steam play options just reinforces that freedom-from-MS initiative.
I think it makes sense in a couple of ways, especially considering how good Wine was getting, and the availability of good GPU drivers on Linux.
From what I'm reading "considering how good Wine was getting" was because valve was paying devs to work on it.
Also, it's nice because basically they've given this all back to the open source community, so it doubly reinforces "freedom-from-MS", because you aren't actually shackled to Steam either.
Also, it's nice because basically they've given this all back to the open source community, so it doubly reinforces "freedom-from-MS", because you aren't actually shackled to Steam either.
Wine's DirectX 6-9 compatibility has been good since ~5 years or so. SC2 has been running well on Wine for about that long. I do wish Wine vs Wine-staging vs Proton forks didn't exist, but as long as they're merging from each other regularly I guess that's the reality.
If you're a dev and want your game to run 20 years from now, as well as it does now, you'd have to think hard about picking DirectX or Metal vs Vulkan considering every game is or soon will be running on Vulkan through Wine/Proton.
If you're a dev and want your game to run 20 years from now, as well as it does now, you'd have to think hard about picking DirectX or Metal vs Vulkan considering every game is or soon will be running on Vulkan through Wine/Proton.
Atari is preparing the launch of its new linux console, the VCS (scheduled for next year). Apart from being a great toy for tinkering, it would be quite interesting if we could run a full steam client and some windows games on it !
Controls may be a bit hazy, but it's definitively something I would try.
Controls may be a bit hazy, but it's definitively something I would try.
You may want to adjust your expectation, as the current Atari is comparable to what Nokia, Polaroid and Kodak are today.
https://www.youtube.com/watch?v=z0qyUhb3VXI
https://www.youtube.com/watch?v=z0qyUhb3VXI
Ah yes Atari, the company that singlehandedly almost destroyed the video game industry with their crapware games. How are they still alive? Just milking old IPs and patents?
I look forward to attempting the new DOOM with a one-button joystick ;)
Sounds like a fun challenge, akin to playing Castlevania: SotN with the Richter character.
This is really interesting. Would anyone have a link into more information as to how they are making this happen behind the scenes? How is this different from wine?
Here are the details from Valve's announcement post [0]:
[begin quote]
Q: What is Proton exactly? How does it differ from normal Wine? Who worked on it?
Proton is a tool distribution based on a modified version of Wine. The included improvements to Wine have been designed and funded by Valve, in a joint development effort with CodeWeavers. Here are some examples of what we've been working on together since 2016:
- vkd3d[source.winehq.org], the Direct3D 12 implementation based on Vulkan
- The OpenVR and Steamworks native API bridges
- Many wined3d performance and functionality fixes for Direct3D 9 and Direct3D 11
- Overhauled fullscreen and gamepad support
- The "esync[github.com]" patchset, for multi-threaded performance improvements
Modifications to Wine are submitted upstream if they're compatible with the goals and requirements of the larger Wine project; as a result, Wine users have been benefiting from parts of this work for over a year now. The rest is available as part of our source code repository for Proton and its modules.
In addition to that, we've been supporting the development of DXVK[github.com], the Direct3D 11 implementation based on Vulkan; the nature of this support includes:
- Employing the DXVK developer in our open-source graphics group since February 2018
- Providing direct support from our open-source graphics group to fix Mesa driver issues affecting DXVK, and provide prototype implementations of brand new Vulkan features to improve DXVK functionality
- Working with our partners over at Khronos, NVIDIA, Intel and AMD to coordinate Vulkan feature and driver support
[end quote]
[0] https://steamcommunity.com/games/221410/announcements/detail...
[begin quote]
Q: What is Proton exactly? How does it differ from normal Wine? Who worked on it?
Proton is a tool distribution based on a modified version of Wine. The included improvements to Wine have been designed and funded by Valve, in a joint development effort with CodeWeavers. Here are some examples of what we've been working on together since 2016:
- vkd3d[source.winehq.org], the Direct3D 12 implementation based on Vulkan
- The OpenVR and Steamworks native API bridges
- Many wined3d performance and functionality fixes for Direct3D 9 and Direct3D 11
- Overhauled fullscreen and gamepad support
- The "esync[github.com]" patchset, for multi-threaded performance improvements
Modifications to Wine are submitted upstream if they're compatible with the goals and requirements of the larger Wine project; as a result, Wine users have been benefiting from parts of this work for over a year now. The rest is available as part of our source code repository for Proton and its modules.
In addition to that, we've been supporting the development of DXVK[github.com], the Direct3D 11 implementation based on Vulkan; the nature of this support includes:
- Employing the DXVK developer in our open-source graphics group since February 2018
- Providing direct support from our open-source graphics group to fix Mesa driver issues affecting DXVK, and provide prototype implementations of brand new Vulkan features to improve DXVK functionality
- Working with our partners over at Khronos, NVIDIA, Intel and AMD to coordinate Vulkan feature and driver support
[end quote]
[0] https://steamcommunity.com/games/221410/announcements/detail...
For what it's worth, this seems reminiscent of other wine distributions like crossover office (for office) or cedega (for games)
In addition to what someone copied and pasted, some python scripts to make sure everything is excuted right. I do need to look into it more though :P
Valve needs to partner with Google and launch a Chromebook/Steam Machine hybrid. It's in the interest of both companies to kill Windows. Google is already adding support for native Linux programs to Chrome OS, they could make a Chrome/Android hybrid that pulls all of the weight of the Android ecosystem and adds to that the weight of Steam. It would be a success and could seriously hurt Microsoft.
I couldn't think of anything worse than Valve and Google partnering.
And I don't know why you would want to 'kill' windows. What Valve is doing is great, its making more competition, that puts pressure on Microsoft to be competitive too. But killing off windows completely hurts everyone. No competition is bad.
And I don't know why you would want to 'kill' windows. What Valve is doing is great, its making more competition, that puts pressure on Microsoft to be competitive too. But killing off windows completely hurts everyone. No competition is bad.
> But killing off windows completely hurts everyone.
Who the hell is competing with windows? Linux can’t meet its standards, and its main draws are being cheap and able to run popular software when macs can’t (I’m being reductive, but it doesn’t really matter much for my point). It already has no competitor. Each OS has its niches where it clearly excels, and they aren’t looking to be competing in the future.
Note, I use all three; I’m unsatisfied with all three. If this is personal, it’s not against just Microsoft.
So, Valve + literally anyone but Apple or Microsoft is amazing news in my book. GNU/Linux/whoever else benefits can use all the help they can get.
Who the hell is competing with windows? Linux can’t meet its standards, and its main draws are being cheap and able to run popular software when macs can’t (I’m being reductive, but it doesn’t really matter much for my point). It already has no competitor. Each OS has its niches where it clearly excels, and they aren’t looking to be competing in the future.
Note, I use all three; I’m unsatisfied with all three. If this is personal, it’s not against just Microsoft.
So, Valve + literally anyone but Apple or Microsoft is amazing news in my book. GNU/Linux/whoever else benefits can use all the help they can get.
> Linux can’t meet its standards, and its main draws are being cheap
It's not cheap for personal computing, most people using linux buy windows laptops and run linux on it.
It's not cheap for personal computing, most people using linux buy windows laptops and run linux on it.
I want Windows dead because it's a proprietary surveillance machine that has stayed alive thanks to really strong lock-in and network effects. I don't trust Google and Valve either, but even if they go full evil empire after after killing Windows, a monopoly built on Linux and Vulkan is a much better place than where we are now.
Google already has a near-monopoly in the smartphone space and it's much better than the Windows monopoly on the desktop. Android being built on tons of GPL software means they have to contribute changes back to the benefit of the FOSS ecosystem. It also means you can easily make/use a custom Android ROM without any proprietary components.
Google already has a near-monopoly in the smartphone space and it's much better than the Windows monopoly on the desktop. Android being built on tons of GPL software means they have to contribute changes back to the benefit of the FOSS ecosystem. It also means you can easily make/use a custom Android ROM without any proprietary components.
You have drinking too much google-aid. I have no love for windows but I am not sure as hell gonna replace it with something under Google's control. The windows surveillance machine pales in front of Google's monster.
> it's much better than the Windows monopoly on the desktop
Android monopoly on the smartphone is the worst kind of monopoly. At least windows give a damn about your security patches and small things such as being able to run the latest version of the OS without invoking arcane rituals. Making a custom ROM without any proprietary components? Not a chance.
I am all for Linux dominance on the desktop but not with any Google DNA in there.
> it's much better than the Windows monopoly on the desktop
Android monopoly on the smartphone is the worst kind of monopoly. At least windows give a damn about your security patches and small things such as being able to run the latest version of the OS without invoking arcane rituals. Making a custom ROM without any proprietary components? Not a chance.
I am all for Linux dominance on the desktop but not with any Google DNA in there.
>You have drinking too much google-aid.
I have no love for Google. I don't even have a Google account.
>Making a custom ROM without any proprietary components? Not a chance.
Lineage, Copperhead, and Replicant exist and work well. And they are all 100% Google-free.
I have no love for Google. I don't even have a Google account.
>Making a custom ROM without any proprietary components? Not a chance.
Lineage, Copperhead, and Replicant exist and work well. And they are all 100% Google-free.
None of the OSes you’ve mentioned work without proprietary blobs if your phone is not supported tough luck.
> I want Windows dead because it's a proprietary surveillance machine
I hope you are aware that anything Google touches is at least a hundred times worse in that regard?
> Android being built on tons of GPL software means they have to contribute changes back to the benefit of the FOSS ecosystem.
Android is built around a ton of proprietary Google technologies and services, the number of which keeps growing. Alternatives will have to be written without industry support since Google forces phone makers to only sell Android phones with full spyware suite active by default and running at 100%. Any phone maker that tries to provide an alternative to Googles services will be cut off immediately, leaving them with warehouses full of bricks. Google is the new Microsoft.
I hope you are aware that anything Google touches is at least a hundred times worse in that regard?
> Android being built on tons of GPL software means they have to contribute changes back to the benefit of the FOSS ecosystem.
Android is built around a ton of proprietary Google technologies and services, the number of which keeps growing. Alternatives will have to be written without industry support since Google forces phone makers to only sell Android phones with full spyware suite active by default and running at 100%. Any phone maker that tries to provide an alternative to Googles services will be cut off immediately, leaving them with warehouses full of bricks. Google is the new Microsoft.
Sorry I don't mean to poke bears or aid trolls, but how so with "Google touches is at least a hundred times worse"?
Surveillance is Google's entire business model, Microsoft just see it as a nice add-on.
They track absolutely everything they can.
Except that Google might soon ditch Linux for both ChromeOS and Android in favor of Fuchsia, which they have direct control over - probably against the long-term best interest of both the community and (hopefully) Valve.
> you can easily make/use a custom Android ROM without any proprietary components.
Uhm... easily? Most phones and tablets cannot even be unlocked / rooted.
> you can easily make/use a custom Android ROM without any proprietary components.
Uhm... easily? Most phones and tablets cannot even be unlocked / rooted.
Looking windows would create the same incentives for Valve. There's no reason to believe a monopoly in any sector of IT doesn't create a proprietary surveillance machine. 2+ competitors create a better environment for that than killing the old machine and replacing it with a new one.
I'm not sure why you think Google is better from the proprietary surveillance point of view than Microsoft either. Being that machine is literally how Google makes money.
I'm not sure why you think Google is better from the proprietary surveillance point of view than Microsoft either. Being that machine is literally how Google makes money.
> Google already has a near-monopoly in the smartphone space and it's much better than the Windows monopoly on the desktop.
Like half the useful apps have problems running without Google Apps being installed. GCM errors, apps refusing to run if the Play Store is not installed, Google making decisions that impact ROM developers. That's what I read about it anyway and discouraged me from trying AOSP without Gapps.
> it's much better than the Windows monopoly on the desktop
Steam is DRM. Gabe bus factor: Microsoft buys Steam and renames it to GFWL Redux
Like half the useful apps have problems running without Google Apps being installed. GCM errors, apps refusing to run if the Play Store is not installed, Google making decisions that impact ROM developers. That's what I read about it anyway and discouraged me from trying AOSP without Gapps.
> it's much better than the Windows monopoly on the desktop
Steam is DRM. Gabe bus factor: Microsoft buys Steam and renames it to GFWL Redux
> Steam is DRM
Nitpick: Steam offers DRM to developers who want it, it does not force games to use DRM. Many games installed via Steam run completely without Steam. The DRM-free games are mostly indie games.
Nitpick: Steam offers DRM to developers who want it, it does not force games to use DRM. Many games installed via Steam run completely without Steam. The DRM-free games are mostly indie games.
microG is indeed a cat and mouse game which you cannot safely rely on. (I'm using it though.)
I'm truly interested and curious. Can you explain to me why being on the internet where all your actions are being monitored by your ISP is OK, but Windows is bad? I mean, no matter how many precautions you take, someone is watching you some how. Use web-based email? There's a record somewhere with all your past emails and they are making a marketing profile about you, same with search.
And what about smart phones? Android has you locked into Google surveillance and Apple is closed so we have no idea how much they know. Send a text? Your provider had to send that data and the person on the receiving end... well, you never know how secure their systems are.
Just some food for thought, would like to hear why Windows is so bad, I'm a Windows/Apple/Linux user and I don't hate on any of them.
And what about smart phones? Android has you locked into Google surveillance and Apple is closed so we have no idea how much they know. Send a text? Your provider had to send that data and the person on the receiving end... well, you never know how secure their systems are.
Just some food for thought, would like to hear why Windows is so bad, I'm a Windows/Apple/Linux user and I don't hate on any of them.
>Can you explain to me why being on the internet where all your actions are being monitored by your ISP is OK
ISP surveillance is not OK, but ISPs only know the domains I access, not what I do on them. I can prevent them from knowing even that by using a VPN, Tor, or any other kind of proxy. I believe encrypted DNS might also become a thing in the future. Also, I'm not locked-in to my ISP.
>no matter how many precautions you take, someone is watching you some how
That's what we're trying to fight.
>There's a record somewhere with all your past emails and they are making a marketing profile about you
A lot of my email accounts are fake-identity and temporary and I try to use encryption whenever I can, but I admit email encryption has a long way to go. There's no lock-in here though.
>Android has you locked into Google surveillance
It doesn't. Custom Google-free Android ROMs are a thing and work well.
>Send a text? Your provider had to send that data
Use encryption. I recommend Matrix/Riot.im for encrypted chat. There is also a program called Silence that can encrypt SMS.
-
If you want to know the point of all this, there's a lot of material online, but you can start by watching the short talk "Why Privacy Matters" by Glenn Greenwald
ISP surveillance is not OK, but ISPs only know the domains I access, not what I do on them. I can prevent them from knowing even that by using a VPN, Tor, or any other kind of proxy. I believe encrypted DNS might also become a thing in the future. Also, I'm not locked-in to my ISP.
>no matter how many precautions you take, someone is watching you some how
That's what we're trying to fight.
>There's a record somewhere with all your past emails and they are making a marketing profile about you
A lot of my email accounts are fake-identity and temporary and I try to use encryption whenever I can, but I admit email encryption has a long way to go. There's no lock-in here though.
>Android has you locked into Google surveillance
It doesn't. Custom Google-free Android ROMs are a thing and work well.
>Send a text? Your provider had to send that data
Use encryption. I recommend Matrix/Riot.im for encrypted chat. There is also a program called Silence that can encrypt SMS.
-
If you want to know the point of all this, there's a lot of material online, but you can start by watching the short talk "Why Privacy Matters" by Glenn Greenwald
Windows is "bad" for the same reason all that you listed is. It's a fallacy to excuse anti-user, anti-privacy practices under the argument that "Well, others do it too".
ISPs are many, Microsoft is one. Regardless of how corrupted and corruptible ISPs are, that’s a huge difference - especially in parts of the world where you have choice of ISPS.
> a monopoly built on Linux and Vulkan is a much better place than where we are now.
No, it’s not. There’s nothing infallible or timeless about either. Linux is already showing its age; vulkan is designed around hardware you can find today, around technologies that are already commoditized. It will also show its age soon, if it has not already.
No, it’s not. There’s nothing infallible or timeless about either. Linux is already showing its age; vulkan is designed around hardware you can find today, around technologies that are already commoditized. It will also show its age soon, if it has not already.
Well, currently there's no much competition with Windows around, right? They managed to get a ~90% share in the desktop market, using debatable practices, which to me looks like a monopoly. It's very difficult to get in there when virtually every PC manufacturer bundles their product.
Why would valve want to replace an OS where MS controls the app store with one where google controls it?
Every threat the MS poses to valve google does as well. Especially when it seems google is angling for Fuschia to be the future.
Every threat the MS poses to valve google does as well. Especially when it seems google is angling for Fuschia to be the future.
Why would the owner of the largest and most profitable software store on Windows want to kill Windows?
There is some weird fan effect with Valve similar to the Google early days where people see them as a universal force for good that will free PC gaming from Microsoft and has the users best interests at heart.
Honestly feel the actual drives of Valve couldn't be further removed from the desires and beliefs of Valve fans.
There is some weird fan effect with Valve similar to the Google early days where people see them as a universal force for good that will free PC gaming from Microsoft and has the users best interests at heart.
Honestly feel the actual drives of Valve couldn't be further removed from the desires and beliefs of Valve fans.
> Valve needs to partner with Google and launch a Chromebook/Steam Machine hybrid.
This disturbing chimera would be such a disaster for computing privacy and agency.
Steam and android are both horribly mismanaged from a technical user standpoint.
This disturbing chimera would be such a disaster for computing privacy and agency.
Steam and android are both horribly mismanaged from a technical user standpoint.
> It's in the interest of both companies to kill Windows
Sorry why is it in both of their interests to do so?
Sorry why is it in both of their interests to do so?
The whole Steam on Linux thing is believed to have started because Valve saw the Windows Store as a threat to their business model. IIRC, at the time it looked like Microsoft would disallow installation of programs from outside sources.
As for Google, well they are just big competitors in a lot of areas. I'm sure they would love to beat Microsoft on the desktop like they did in the smartphone space.
As for Google, well they are just big competitors in a lot of areas. I'm sure they would love to beat Microsoft on the desktop like they did in the smartphone space.
The official version is that Gabe Newell thought Windows 8 to be a catastrophe, presumably due to the horrible UI. That Microsoft would single-handedly crash the PC market and take down Steam with it.
So, they wanted to become less dependent on Microsoft in general.
Windows 10 is somewhat less of a catastrophe in the UI department (though there is something to be said about mostly being able to ignore the mobile UI in Windows 8), but it's still controversial with its often illegal data collection. I mean, it's probably not going to happen, because the entire world depends on it, but theoretically countries could still block the sale of Windows 10.
But yeah, I don't believe myself either that the Windows Store is not seen as a threat. When you own a platform, you can push pretty much any software to be dominant on it.
Windows 10 is somewhat less of a catastrophe in the UI department (though there is something to be said about mostly being able to ignore the mobile UI in Windows 8), but it's still controversial with its often illegal data collection. I mean, it's probably not going to happen, because the entire world depends on it, but theoretically countries could still block the sale of Windows 10.
But yeah, I don't believe myself either that the Windows Store is not seen as a threat. When you own a platform, you can push pretty much any software to be dominant on it.
Would Valve not rather have Microsoft than Google then? Windows users have administrator accounts and can install steam and its games without issue. Google play store would directly compete with steam.
No, because Google doesn't wield the same power over Android that Microsoft wields over Windows. If Google decided to disallow Steam from Android, Valve could just fork Android and carry on. They can't do that with Windows.
That's optimistic...
Google exerts a lot of power over Android.
The EU did recently punish Google for that, so theoretically Google now has to stop with it, but up until this point, they forced manufacturers to only ever preinstall the Google version of Android (or permanently lose their license to preinstall the Google Apps) and also forced manufacturers to always install the whole Google app bundle, not just the Play Store.
To put their power into perspective, just remember that Amazon has been in the game of distributing an Android fork and alternative app store for a while now. And Amazon is magnitudes bigger than Valve.
Google exerts a lot of power over Android.
The EU did recently punish Google for that, so theoretically Google now has to stop with it, but up until this point, they forced manufacturers to only ever preinstall the Google version of Android (or permanently lose their license to preinstall the Google Apps) and also forced manufacturers to always install the whole Google app bundle, not just the Play Store.
To put their power into perspective, just remember that Amazon has been in the game of distributing an Android fork and alternative app store for a while now. And Amazon is magnitudes bigger than Valve.
It's not optimistic, just simplified. Surely you agree that Valve could escape Google's claws on Android much more easily than they can escape Microsoft claws on Windows? Heck, they could even partner with Amazon!
I do think so, yes, but I also think that they still could not actually escape. That they'd go bankrupt within a year, or at least that they'd have to shrink their operation to only cover the Chinese market, which doesn't have access to the Play Store, but also isn't terribly excited for yet another US company trying to enter their market.
Do you mean Android the open source project that pretty much everyone agrees is mostly useless on its own? Or Android as in Google Play, the proprietary software that Google controls fully?
It was easy. They just started using the same name, “Android”, for loads of proprietary stuff, and the geeks didn't care because they were too busying sucking up to Google for not being Microsoft.
It was easy. They just started using the same name, “Android”, for loads of proprietary stuff, and the geeks didn't care because they were too busying sucking up to Google for not being Microsoft.
AOSP is not "useless own its own". I don't know how you got that idea. Custom ROMs are every bit as capable as Google-flavored Android.
I said “mostly” useless on its own.
I believe Lineage and co have to supply their own replacements for some important features, and/or use the proprietary Google Play Services.
AOSP isn't a usable base product, like Chromium for example.
(That's my understanding anyway. It's quite possible I'm wrong!)
I believe Lineage and co have to supply their own replacements for some important features, and/or use the proprietary Google Play Services.
AOSP isn't a usable base product, like Chromium for example.
(That's my understanding anyway. It's quite possible I'm wrong!)
You can't "just fork Android". Android devices come pre-installed with Android right now. OEMs aren't allowed by Google to distribute a non-official Android version. Its Microsoft all over again.
That is a ridiculous statement
Time spent not in a browser is time spent where Google might not be able to see what you're doing.
Considering that their business is watching what you do all the time...
Considering that their business is watching what you do all the time...
As far as valve goes, the windows store is a potential competitor to steam.
I'm an avid gamer and would never buy anything from the Windows store. Casual players even use Steam. I'd like to see the sales stats between the WS and Steam to compare.
I can confirm that!
I had to download Gears of War 4 from the Windows Store because it was distributed there. I had a terrible experience: account not logging, download not initiating etc.
In the end I had to download it on my laptop whose Store was seemingly working better and transfer the files over to the Desktop.
My experience is that WS is very fragile and much less reliable than Steam.
That something I never understood the Xbox store works pretty much flawlessly.
How hard do you need to work to screw up something that already works just fine.
If I had to guess I'd say by having it reimplemented in a different department... MS in the past has shown very severe symptoms of NIH between teams.
You are talking about the next month, but this game plays over a decade. I remember the mid. And even late ‘90s when gamers said they would never ever run games in windows, DOS is forever!
Times change.
Times change.
The Chromebook is the polar opposite of what's required for mainstream gaming. Wrong architecture, super-low perf, low storage.
The only way this happens is via streaming. You can already do that.
The only way this happens is via streaming. You can already do that.
> Valve needs to partner with Google and launch a Chromebook/Steam Machine hybrid.
"Valve needs to"? Or you'd like Valve to?
> It's in the interest of both companies to kill Windows. [...] It would be a success and could seriously hurt Microsoft.
Ah, there it is, your real motive. Valve will do whatever will make them money and keep their users mostly happy. I doubt they have much incentive to "kill Windows", and they definitely won't do it just to pander to an anti-MS zealot such as yourself.
"Valve needs to"? Or you'd like Valve to?
> It's in the interest of both companies to kill Windows. [...] It would be a success and could seriously hurt Microsoft.
Ah, there it is, your real motive. Valve will do whatever will make them money and keep their users mostly happy. I doubt they have much incentive to "kill Windows", and they definitely won't do it just to pander to an anti-MS zealot such as yourself.
There were rumors not long ago about Google working on a game console or streaming service.
Kill Windows...and replace it with Steam/Linux? Don't pretend that a proprietary data mining platform that licenses titles behind DRM is in anyway better than Windows [1].
No, my fears are that this will only serve to grow the proprietary ecosystem on Linux and make general users reliant like Google has done to Android. Yes, Android runs on a base Linux kernel and userspace, but what use is that when users are totally reliant on Google services? Likewise, if users require Steam, etc, than the core OS running underneath that application matters little.
[1] https://store.steampowered.com/privacy_agreement/
[..] information about the device you are using, including what operating system you are using, device settings, unique device identifiers, and crash data.
No, my fears are that this will only serve to grow the proprietary ecosystem on Linux and make general users reliant like Google has done to Android. Yes, Android runs on a base Linux kernel and userspace, but what use is that when users are totally reliant on Google services? Likewise, if users require Steam, etc, than the core OS running underneath that application matters little.
[1] https://store.steampowered.com/privacy_agreement/
[..] information about the device you are using, including what operating system you are using, device settings, unique device identifiers, and crash data.
Does anyone know why Valve forked the Wine rather than joining them?
From the FAQs of the original post on Steam:
"Modifications to Wine are submitted upstream if they're compatible with the goals and requirements of the larger Wine project; as a result, Wine users have been benefiting from parts of this work for over a year now. The rest is available as part of our source code repository for Proton and its modules."
Wine has very tight/strict requirements for what can merged into its codebase, it's why DXVK has had to remain a standalone project because it doesn't live up to Wine's code/goal requirements.
"Modifications to Wine are submitted upstream if they're compatible with the goals and requirements of the larger Wine project; as a result, Wine users have been benefiting from parts of this work for over a year now. The rest is available as part of our source code repository for Proton and its modules."
Wine has very tight/strict requirements for what can merged into its codebase, it's why DXVK has had to remain a standalone project because it doesn't live up to Wine's code/goal requirements.
Can you be more specific on where the goals differ?
"Get all windows stuff to run perfectly in Linux" sounds like a pretty simple goal to me.
"Get all windows stuff to run perfectly in Linux" sounds like a pretty simple goal to me.
But that is not the goal for Proton. Proton does not need to be able to run Photoshop or Powerpoint. There is optimizing to be done if you can skip the majority of desktop software as run target.
Wine (and I'm sure Proton) has a ton of app/game specific fixes. It's entirely reasonable for Valve to desire changes that Wine doesn't want to bring upstream.
IIRC DXVK is written in C++ while WINE is written in C.
Wait, so Wine has been accepting pull requests from Valve developers for a whole year and nobody has noticed? How did they keep that under wraps?
Who do you think should have noticed and informed the world?
The main Wine devs knew but were probably asked not to tell anyone, and apart from them I don't think many people scrutinize so much the personal details of all the people who submit pull requests in all the open source projects.
The main Wine devs knew but were probably asked not to tell anyone, and apart from them I don't think many people scrutinize so much the personal details of all the people who submit pull requests in all the open source projects.
Thanks.
They said they work on their own fork and push everything back to upstream when its appropriate. I guess that gives them the freedom to do anything without worrying if upstream will accept it.
Pure speculation, but it looks like Valve has a tight focus on DXVK whereas I think Wine is a bit more broad in it's support goals.
Would be great if they could do that for Mac as well, although Metal is a deadend (for game devs) so they may not bother. I have had some decent success running wine games on Mac.
On the proton github repo there are instructions for building for Mac and moltenvk libraries. It’s probably not as mature as the Linux version but there are bits hinting here and there. Link: https://github.com/ValveSoftware/Proton
I wouldn't be surprised if this is something that will "support Macs" being a library used for official releases, since there's generally more commercial support for Macs and porting houses likely to incorporate and contribute to this directly.
At least it's my hope, it could also be there's just a big unknown with what happens to WINE/tools like this when macOS doesn't support 32-bit apps anymore.
At least it's my hope, it could also be there's just a big unknown with what happens to WINE/tools like this when macOS doesn't support 32-bit apps anymore.
There is the moltenVK project. So they could do a similar thing to what they did with DXVK.
It supposedly works on Mac. MoltenVK is a thing
Unless game devs are going to not support Mac, Apple is deprecating OpenGL so they'll need to use Metal.
This could be the year of the Linux Desktop!
Why can't we just have native support... Why do almost everyone had to go for Wine instead of native support. Gaming on Wine is painful and often break with updates.
> Why can't we just have native support...
Because the market for Linux gamers -- especially ones who don't already dual-boot Windows -- is tiny.
Because the market for Linux gamers -- especially ones who don't already dual-boot Windows -- is tiny.
I think it's interesting that tiny indie projects would often have a Linux port, when their user base isn't all that big to begin with and their Linux user base would be much smaller still. On the other hand, AAA titles which would presumably still sell tens of thousands of copies rarely ever seem to make the effort.
I'm not complaining, but shouldn't it be the other way around?
I'm not complaining, but shouldn't it be the other way around?
AAA titles are probably more graphically complex, especially in terms of low-level shortcuts/optimizations. Whereas most indie titles have simple enough graphics to make extra optimization unnecessary.
The top reasons I've seen indie devs mention for doing linux support are either "I write the code on linux, so it makes sense to have the game work there" or "I do it because it's the right thing to do to make my passion project to more people". Never because it was financially worth it.
Indie titles often use either a custom game engine that is easy to port or use something like Unity that has built-in Linux support. AAA titles are harder to port because they're more complex.
Even most native ports, made by third parties like feral, use a compatibility layer not unlike Wine internally.
As long as a game is supported, works well and has decent performance, it should be sufficient; everything else is implementation details. This might require shipping the right version of wine with the game itself of course which seems to be what Valve is planning to do.
As long as a game is supported, works well and has decent performance, it should be sufficient; everything else is implementation details. This might require shipping the right version of wine with the game itself of course which seems to be what Valve is planning to do.
If you give me a black box of code, and I can't tell the difference, I don't care what is in the box. The primary things to be concerned about are A) support (which sounds like valve is covering themselves, not that they are notorious for great support), and B) performance.
If something is performant and it works, who cares how it got there. If either of those things aren't there, then I could see how the frustration kicks in.
In the mean time, I have a ton of friends who have been saying "I would use Linux but my games" for years now that might actively take the plunge.
As proton evolves and gets better, I fully expect more devs to make minor tweaks to make their game play nicer with proton, which is far easier to do than making a full linux build. Which means overall, the games getting betters, and the tools getting better, this is great news for gaming on linux.
Now I wonder how proton will play out for non steam games. If proton is basically "game-centric wine", will I be able to use it to play Overwatch?
If something is performant and it works, who cares how it got there. If either of those things aren't there, then I could see how the frustration kicks in.
In the mean time, I have a ton of friends who have been saying "I would use Linux but my games" for years now that might actively take the plunge.
As proton evolves and gets better, I fully expect more devs to make minor tweaks to make their game play nicer with proton, which is far easier to do than making a full linux build. Which means overall, the games getting betters, and the tools getting better, this is great news for gaming on linux.
Now I wonder how proton will play out for non steam games. If proton is basically "game-centric wine", will I be able to use it to play Overwatch?
Because developers target DirectX rather than OpenGL/Vulkan. There is the whole "commercially viable" aspect as well.
This makes GNU/Linux a more appealing and viable gaming platform than Mac OS, since it now has the opportunity to capture so many of the existing Windows games.
Just run your macOS (not Hackintosh) on my Ryzen and then we'll talk.
Samba was reverse engineered, MS somewhat tried to make it an open standard, now are agnostic to it and are still developing closed extensions.
Mono became big enough, and they opensourced their own CLR, and it runs on Linux.
DirectX was implemented as a compatibility layer and runs games at close to native speeds on Linux and MS dumps it for Vulkan. Or so the wish goes.
Mono became big enough, and they opensourced their own CLR, and it runs on Linux.
DirectX was implemented as a compatibility layer and runs games at close to native speeds on Linux and MS dumps it for Vulkan. Or so the wish goes.
This is awesome. As others have said, gaming is one of the few reasons I still use Windows on my desktop.
Heh, I wonder if the list is correct about its Doom games. It links to the 2016 Doom as well as DOOM II: Hell on Earth (1994). Silly trend of re-using old names for new releases, they might have mean the original Doom instead...
Both are on the list, Ultimate Doom further down is a re-release of the original.
Has anyone addressed the possible legal issues with this type of emulation?
What about titles with strong DRM is it likely that they will run in these environments?
In Valve's announcment they mention that titles with strong DRM or complex anti-cheat measures probably won't work.
Oh, thank goodness. I could never get the Steam client running under Wine. Usually, nothing happens.
Does this mean we can now have wine without breaking packages and having to reinstall?
If you use Wine to play DirectX 9 games, try the d3d9 fork. It's a fork with patches that give a much increased performance with DirectX 9 games which aren't merged into the Wine mainline because of the usual bikeshedding reasons. I use it to play WoW and I get better performance than on Windows.
https://packages.gentoo.org/packages/app-emulation/wine-d3d9
https://packages.gentoo.org/packages/app-emulation/wine-d3d9
> I get better performance than on Windows
as anecdotal as it might be, I used to get better performance from wine'd dwarf fortress than with it's osx port, which is interesting I guess.
as anecdotal as it might be, I used to get better performance from wine'd dwarf fortress than with it's osx port, which is interesting I guess.
I don’t know how it is today but Microsofts compiler used to produce much better code than the free compilers used on Linux and Mac OSX
Just because the compiler is good, doesn't mean the OS's CPU scheduler is any good. Nor does it mean the graphics drivers for that OS are any good. Same for the filesystem. etc.
I’m not sure how that has anything to do with the difference in performance between running the Windows version on OSX and running the OSX version on OSX.
clang is doing pretty nicely compared to MSVC these days: https://news.ycombinator.com/item?id=17504197
That’s great but Dwarf Fortress is a 2006 game, It was probably compiled using gcc.
Back in the days of vanilla... WoW client has built-in native OpenGL support and was working perfectly under Wine.
BTW. Same with W3
BTW. Same with W3
I don't know why it is in my case, but I suspect it's because Wine and/or the AMD drivers on Linux don't implement as many visual effects as there are on Windows, which makes the game easier on the GPU.
I think that wine also used to drop silently shaders/features that couldn't emulate, so each single frame is easier for the gpu.
Borderlands 2 is known for running better on wine than on Windows. IIRC the reason was the filesystems (ext4 vs ntfs).
I used to be a big Wine user back when I believed in the potential for a commodity Linux desktop for normal people. These days I can’t for the life of me figure out why someone would want to run games on Wine instead of dual booting to Windows when it’s game time.
A few reasons:
* License cost
* HDD / SSD storage space
* OS performance
* They might not agree with the EULA
* Or simply because they just don't don't like Windows.
All correct. Also, I booted into Windows on Saturday to play a game, it hadn't been booted in months, so I hat to wait for a forced SP install and Windows wiped out Grub. Every time I boot back into Windows it kills Grub and I have to fix it again. Not only did I lose all my gaming time to the updates, I lost extra time fixing my bootloader because of Windows' aggressive BS. The sooner I can get it gone the better and I'll free up an entire SSD for games.
I just have two hard drives for this reason, super super annoying.
I dual booted for a while but I found myself using Windows so infrequently that whenever I booted it up I'd wind up spending hours updating everything. In the end I decided it was far too much hassle.
Incidentally my "game time" these days is much more likely to be on my 486 PC, Atari 800 or Dreamcast. I don't have much time to game so being able to jump in immediately and not be interrupted trumps the latest-and-greatest blingy graphics any day.
Incidentally my "game time" these days is much more likely to be on my 486 PC, Atari 800 or Dreamcast. I don't have much time to game so being able to jump in immediately and not be interrupted trumps the latest-and-greatest blingy graphics any day.
We don't like being spied on.
I don't want to use Windows ever again in my life (of course I'm talking about the current software made by the current software company, not the name Windows, this isn't a religious issue).
Also, rebooting takes ages. My Linux boot time might be measured in seconds, but I'm always in the middle of some kind of work and I use my running system to maintain continuity. It's a major pain in the arse to reboot, so I do it rarely.
Also, rebooting takes ages. My Linux boot time might be measured in seconds, but I'm always in the middle of some kind of work and I use my running system to maintain continuity. It's a major pain in the arse to reboot, so I do it rarely.
I don't have to close my browser tabs.
This...
It takes me a good 20m to reboot. 5m for the actual reboot and 15m to check to see if I'll lose any work.
Also - I tend to multitask. Dip into games, dip into work, browsing etc. It's not a concerted change of mode so closing one side of my mind down for a single purpose just doesn't work for me.
It takes me a good 20m to reboot. 5m for the actual reboot and 15m to check to see if I'll lose any work.
Also - I tend to multitask. Dip into games, dip into work, browsing etc. It's not a concerted change of mode so closing one side of my mind down for a single purpose just doesn't work for me.
This this this. Rebooting is a-ok if all you use the computer for is games. But then you don't need to reboot because you're in Windows already.
If you use the computer for multiple purposes, rebooting to play a game will disrupt your environment way too much.
While I do dual boot, I have booted Windows like 2 times this year. The rest, I played ported games. There are a lot of them.
If you use the computer for multiple purposes, rebooting to play a game will disrupt your environment way too much.
While I do dual boot, I have booted Windows like 2 times this year. The rest, I played ported games. There are a lot of them.
Because they don't want to use Windows, period.
You could just virtualize it, dual-booting isn’t even needed. Then create private NAT and only whitelist certain ports and traffic. Hardware assisted virtualization is actually faster in certain cases and workloads than native these days.
If you don't want to use it (many reasons), virtualizing or dualbooting doesn't really make a difference.
You make it sound as if it is trivial to configure the GPU passthrough.
Also, you'll need two graphics adapters for this.
Also, you'll need two graphics adapters for this.
It's not that hard to setup these days honestly, I think the requirement of having 2 GPUs is a turnoff for a lot of people though.
And I think it's been catching on a lot more now that both Intel offers VT-d standard in most of it's chips. So does AMD with its SVM equivalent.
I like this approach Valve is taking better than resorting to VMs though. I'll probably continue to use my GPU passthrough setup for now but when the game compatibility on this gets better I'll likely switch.
And I think it's been catching on a lot more now that both Intel offers VT-d standard in most of it's chips. So does AMD with its SVM equivalent.
I like this approach Valve is taking better than resorting to VMs though. I'll probably continue to use my GPU passthrough setup for now but when the game compatibility on this gets better I'll likely switch.
So an intel CPU + discrete GPU fills the requirement?
Also novidia is known to block driver installs from a VM because “you should be using a professional GPU for that” but there are ways to trick the installer.
Also novidia is known to block driver installs from a VM because “you should be using a professional GPU for that” but there are ways to trick the installer.
AMD has no such problems.
Correct, it is way easier to setup with kvm. Would highly recommend AMD cards for this over nVidia.
I'm using VMs but not for gaming, just running Linux guests on Linux host. virgl works pretty well now for that purpose. But what's really missing is SR-IOV. AMD so far didn't want to support it in regular cards.
Setup can still be a bit annoying.
If I imagine the average PC gamer, I don't think they would be able to troubleshoot any problems. Once you get into setting up storage pools (libvirt) or having to edit the libvirt XML file (want to have host native Audio?) and of course installing all those drivers for optimal performance (digging up the correct CD image and mounting it is not trivial either.
If I imagine the average PC gamer, I don't think they would be able to troubleshoot any problems. Once you get into setting up storage pools (libvirt) or having to edit the libvirt XML file (want to have host native Audio?) and of course installing all those drivers for optimal performance (digging up the correct CD image and mounting it is not trivial either.
Isn't the 2 GPU requirement just for running native graphics concurrently on both systems? You can still use the Linux host remotely over the network.
edit: here's a receipe: https://github.com/joeknock90/Single-GPU-Passthrough
edit: here's a receipe: https://github.com/joeknock90/Single-GPU-Passthrough
The other issue going down the HVM route is the number of multiplayer platforms e.g. Steam that ban users running inside of a hypervisor[1]. From their perspective it masks the existence of things like memory manipulation tools and other cheating devices.
[1] - https://steamcommunity.com/discussions/forum/9/1355103931983...
[1] - https://steamcommunity.com/discussions/forum/9/1355103931983...
My laptop came with Windows pre-loaded on the original SSD. No installation medium obviously, other than the recovery partition. I'm curious if it even loads if I tell Virtualbox to load it from that drive, given that the hardware it presents in a virtualized system is significantly different from the actual laptop hardware.
got any tips for a starting point on that (hardware assisted virtualization)? I'd be super interested.
what host os, guest os, virtualization stack (vmware??), video card combo is working for you?
Cheers.
what host os, guest os, virtualization stack (vmware??), video card combo is working for you?
Cheers.
Some games (mostly older ones) run faster (higher fps) on Linux via Wine, compared to when they run natively on windows.
I have my dual boot on 2 separate SSDs and personally find it nice to keep gaming and research separate; there is no temptation to game during the week this way. As an aside, curious why some of these reboot times take so long.
Windows costs money.
windows start time is too long
I can reboot my Windows 10 desktop in a few second. The only reason I put my desktop to sleep is that I don't trust the hibernation to maintain my application state...
Since Windows 8, Windows uses a form of hibernation internally. When there's no updates to install, it doesn't actually shut down in the classic sense. Instead, it closes any applications, then hibernates the OS. So, it writes the contents of the RAM to the hard drive, then it powers off.
When it's being powered on again, it just loads that state from the hard drive, rather than running a boot process, which results in significantly better boot times. It however also has drawbacks. It can cause instabilities and it leaves the hard drive in some unworkable state.
The latter is why most people will want to turn this feature off when dual booting. If you don't turn it off and you only have one hard drive with partitions for each OS, you're actually not going to be able to boot Linux (or install it in the first place).
If you have physically separate hard drives, you're not going to be able to access files on your Windows drive, which if it's a gaming-only system might not be as important, but otherwise is still kind of handy.
When it's being powered on again, it just loads that state from the hard drive, rather than running a boot process, which results in significantly better boot times. It however also has drawbacks. It can cause instabilities and it leaves the hard drive in some unworkable state.
The latter is why most people will want to turn this feature off when dual booting. If you don't turn it off and you only have one hard drive with partitions for each OS, you're actually not going to be able to boot Linux (or install it in the first place).
If you have physically separate hard drives, you're not going to be able to access files on your Windows drive, which if it's a gaming-only system might not be as important, but otherwise is still kind of handy.
I have not disabled the fast boot options in Windows and yet I am still able to mount my NTFS formatted boot drive in my Linux install. The existence of a hibernate file does not mean the disk is somehow unworkable.
>I truly do feel that emulation of some sort is a proper technical direction for gaming on Linux. It is obviously pragmatic in the range of possible support, but it shouldn’t have the technical stigma that it does. There really isn’t much of anything special that a native port does – we still make OpenGL calls, winsock is just BSD sockets, windows threads become pthreads, and the translation of input and audio interfaces don’t make much difference (XInput and Xaudio2 are good APIs!). A good shim layer should have far less impact on performance than the variability in driver quality.
>Translating from D3D to OpenGL would involve more inefficiencies, but figuring out exactly what the difficulties are and making some form of “D3D interop” extension for OpenGL to smooth it out is a lot easier than making dozens of completely refactored, high performance native ports.
https://www.reddit.com/r/linux/comments/17x0sh/john_carmack_...