Valve Rolls Out Wine-Based “Proton” for Running Windows Games on Linux
phoronix.com
phoronix.com
>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_...
Some people post which drivers they used, especially when it didn't work.
If you get a game to work, take the time to head over and add your experience.
Too bad, I'm pretty happy with my nvidia card...
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.
Though I would consider this unlikely.
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.
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!
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.
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.
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.
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."
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 only major platform using C# is Unity, and there are a few AAA games written in it, like KSP.
I found someone did a HackWeek project at Unity this year of porting the Unity engine to .net core that has more details:
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
[0]https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-se...
When it's in their interest to be so, don't expect them to start giving away their bread and butter.
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.
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 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.
The current state of computing is less and less about being pro people, and more and more about pro big players.
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.
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.
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.
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.
This was before Apple stopped caring about OSX/macOS though, so not sure this would still happen..
Needs to be in less places, not more.
Of course... it's still a long and difficult road for Valve here, given how well emulation will need to work to accomplish this.
Some say there are games that have noticeable stutters or bottlenecks on Windows that doesn't share the same issues on Wine.
https://github.com/disks86/VK9
https://steamcommunity.com/games/221410/announcements/detail...
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...
I remember that music! Good old days :)
I could not play Oblivion on Windows10 but worked on Wine for me.
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.
(I genuinely can't believe I'm posting this comment completely un-ironically, but here we are).
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.
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
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.
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.
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.
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.
Only on Linux, which is kinda my point. Other platforms are actually, you know, platforms.
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.
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.
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.
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.
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.
* 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...
https://github.com/FWGS/xash3d
It's also got an excellent Android port:
Even without emulation it is impressive how much of Steam's library is available on Linux.
https://docs.google.com/spreadsheets/d/1DcZZQ4HL_Ol969UbXJmF...
Is this a Freudian slip from one of those robosexuals?
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.
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.
In that sense, the more bad reviews the better!
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).
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.
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.
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.
[1]https://wiki.debian.org/Steam#A64-bit_systems_.28amd64.29
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.
> 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.
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.
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.
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 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.
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
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.
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
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.
Its obvious this is the long term plan for MS. Apple has already shown people will buy locked down systems.
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.
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.
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.
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.
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.
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.
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.
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.
Controls may be a bit hazy, but it's definitively something I would try.
[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...
Sorry why is it in both of their interests to do so?
Times change.
Considering that their business is watching what you do all the time...
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.
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 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.
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!)
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.
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.
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.
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
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.
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.
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.
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
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.
> 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.
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.
It's also possible to get an AOSP device de-googled, or to de-google one.
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.
> you can easily make/use a custom Android ROM without any proprietary components.
Uhm... easily? Most phones and tablets cannot even be unlocked / rooted.
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.
It's not cheap for personal computing, most people using linux buy windows laptops and run linux on 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.
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.
The only way this happens is via streaming. You can already do that.
"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 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.
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.
"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.
"Get all windows stuff to run perfectly in Linux" sounds like a pretty simple goal to me.
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.
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.
Because the market for Linux gamers -- especially ones who don't already dual-boot Windows -- is tiny.
I'm not complaining, but shouldn't it be the other way around?
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 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?
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.
https://packages.gentoo.org/packages/app-emulation/wine-d3d9
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.
BTW. Same with W3
Also, you'll need two graphics adapters for this.
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.
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.
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.
edit: here's a receipe: https://github.com/joeknock90/Single-GPU-Passthrough
what host os, guest os, virtualization stack (vmware??), video card combo is working for you?
Cheers.
[1] - https://steamcommunity.com/discussions/forum/9/1355103931983...
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.
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.
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.
* 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.
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.
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.
A large part of my "game time" is on emulated PS2, so I guess I'm way younger than you. :)