Steam Gets Built-in Tools To Let You Run Windows Games on Linux -- Now Available in Beta (pcgamesn.com) 206
Steam Play -- Valve's name for its cross-platform initiative -- is getting a major update, adding built-in tools that would allow users to run Windows games on Linux. It's now available in beta. From a report: The new tools run on Proton, which is custom distribution of the widely-used Wine compatibility tool. In the most practical terms, this means you can now download and install Windows games directly from the Steam client without any further fuss. Valve is currently checking "the entire Steam catalog" and whitelisting games that run without issue, but you can turn off those guidelines and install whatever you want, too.
Proton should provide enhanced performance over Wine in many cases, according to Valve. DirectX 11 and 12 implementations are now based on Vulkan, and performance in multi-threaded games "has been greatly improved compared to vanilla Wine." You'll also see better fullscreen and controller support with Proton. It's also fully open source.
Proton should provide enhanced performance over Wine in many cases, according to Valve. DirectX 11 and 12 implementations are now based on Vulkan, and performance in multi-threaded games "has been greatly improved compared to vanilla Wine." You'll also see better fullscreen and controller support with Proton. It's also fully open source.
Works (Score:5, Informative)
Working well for me so far. Windows games are installing and running. Some people are just adding the path to their Windows Steam games in the Linux Steam client and find that Steam Play is running those games!
Hopefully this doesn't give companies an excuse to ignore native Linux development.
Re:Works (Score:5, Insightful)
Hopefully this doesn't give companies an excuse to ignore native Linux development.
How is a Wine app on a GTK+ system any less "native" than a Qt app on a GTK+ system? It's literally just a different set of userspace libraries.
Re:Works (Score:5, Informative)
How is a Wine app on a GTK+ system any less "native" than a Qt app on a GTK+ system? It's literally just a different set of userspace libraries.
Wine is a layer in the middle that adds some inefficiency, compatibility issues and bugs of its own. Albeit not much - the Wine devs are pretty awesome to do what they do - but it's there.
The biggest issue with companies ignoring "native" Linux is they'll tend to stick with the tools for the platforms they target and they will tend towards the most modern APIs particularly for graphics where modern generally means faster and with more features.
Wine is always playing catch-up with those APIs so there's a very good chance today's Windows game will be years before it's even half playable on Linux using Wine.
If the dev tests on Wine (Score:5, Interesting)
Wine is a layer in the middle that adds some inefficiency, compatibility issues and bugs of its own.
How much more so than GTK+ as "a layer in the middle" between an application and Xlib?
The biggest issue with companies ignoring "native" Linux is they'll tend to stick with the tools for the platforms they target and they will tend towards the most modern APIs particularly for graphics where modern generally means faster and with more features.
How much of this issue goes away if a developer instructs quality control to treat Wine as a fully supported platform alongside Windows 7 and Windows 10? That's how BGB (Game Boy debugger), FCEUX (NES debugger), OpenMPT (sample based sequencer), and FamiTracker (chiptune sequencer) work: the developer ships Win32 binaries tested on both Windows and Wine.
Re: (Score:2)
How much of this issue goes away if a developer instructs quality control to treat Wine as a fully supported platform alongside Windows 7 and Windows 10?
All of it, practically speaking. Wouldn't that be nice?
Re: (Score:2)
It depends upon how well any particular Linux distribution is aligned with Wine and the various hardware drives to produce a solid reliable outcome, probably with a drop in performance, to ensure no game crashes the system but can crash wine. So you never need to reboot the system, only reboot wine, its for gaming afterall and so you want other things to run liably as well. This tied to a more modern era of in home servers, keeping the corporations out and you family privacy in ie your own in home encrypted
Re: (Score:2)
That doesn't feel right (I want muh NATIVE ELF BINARIES!), but it makes perfect sense: If Wine is a supported platform then there's nothing really to worry about.
Re: (Score:2)
or in the case of say Bethesda games where they can be "stability impaired" even running NATIVE.
You don't want to add "while on fire" to the problem of crossing an olde Wooden Bridge (or one that was made with 3d printed parts)
Re: If the dev tests on Wine (Score:2, Interesting)
How can you be so stupid.GTK and QT and Motif are widget sets. Precanned libraries containing styling for drop-down lists and buttons and so on, drawn as bitmap on your screen. On windows you get only 2 - aero and GDI and with Windows 10 only one style again... wine is a completely different beast
High level (Score:5, Informative)
Wine is a layer in the middle that adds some inefficiency, compatibility issues and bugs of its own.
How much more so than GTK+ as "a layer in the middle" between an application and Xlib?
Much more, for the reason that GTK+ is a layer that provides high-level functionnality (I want a button, I want a window, I want a drop list, etc.) to the application, while itself talking to a low level interface (mostly used for blitting and rectangles filling).
What wine is doing is taking a certain low-level API and reconverting everything into a completely different low-level API.
It would be like if you took that Xlib API, but instead talking to the Xlib library it self, you talk to a separate layer that takes in Xlib API and translates it into something that is displayed using openGL, running on SDL, so that it could be used on some weird gaming console, because that GTK+ application is compiled with a GTK version hard-coded in that isn't supporting OpenGL.
Could be entirely solved by having that application built with GTK supporting OpenGL as a render back-end, but it cannot be done, because you have zero control on it, thus you need a rube goldberg layer of pancackes of middle layers to get the application working.
Wine is that adaptation layer.
That's why it would be great if eventually one day developers started to target Linux too.
But until then, there's the chicken-and-egg problem of linux not being a popular gaming platform, thus not worth spending resources on from the developers point of view, and in turn never getting popular because there are no games on it.
Thus...
How much of this issue goes away if a developer instructs quality control to treat Wine as a fully supported platform alongside Windows 7 and Windows 10? That's how BGB (Game Boy debugger), FCEUX (NES debugger), OpenMPT (sample based sequencer), and FamiTracker (chiptune sequencer) work: the developer ships Win32 binaries tested on both Windows and Wine.
Yup, developers at least starting to give attention to wine is a good intermediate step.
That at least solves the "users won't pick up linux as a platform due to lack of games" part of the equation.
And who knows, maybe this will suddenly make steam-on-linux a popular platform (maybe because it could enable cheap linux "steambox" gaming consoles ?)
And once these "steambox" gaming console become popular enough to show on the radar of the devs, some will try putting effort into true native linux builds, eventually ?
XServer XSDL app for Android (Score:2)
It would be like if you took that Xlib API, but instead talking to the Xlib library it self, you talk to a separate layer that takes in Xlib API and translates it into something that is displayed using openGL, running on SDL
Or shorter: "an X server that uses SDL for output," like the "XServer XSDL" app for Android [google.com]. That and the "GNURoot Debian" app are necessary in order to get existing applications running on some popular Linux-based distributions, as they come with Linux proper (a kernel) but not GNU or X.
Re: (Score:2)
How much does windows really cost on a computer?
Re: (Score:2)
A Windows 10 Home license for a home-built PC costs $119.99.
Re: (Score:2)
the developer ships Win32 binaries tested on both Windows and Wine.
The difference is an app directly targets GTK and if xlib changes GTK wraps that.
The situation I tried to pose is one where an app directly targets Wine alongside Windows. Then if Xlib changes, Wine wraps that. How could I have got that across better?
Re: If the dev tests on Wine (Score:5, Insightful)
You're comparing a set of libraries that (GTK/QT) that you install on a BSD/linux/whatever system
Wine is a set of libraries too: sudo apt install wine-development
which a natively compiled
Wine is also natively compiled for x86 and x86-64 architectures.
intended to be there
If it weren't "intended to be there", I don't see why it would be in the default repositories of major desktop X11/Linux distributions, ready for the administrator to install.
with an entire emulation layer that emulates / translates everything from a network stack
glib-networking [gnome.org]
mouse/[...]/keyboard
GTK+ event handling [gnome.org]
modem
NetworkManager [gnome.org]
video
GDK [wikipedia.org], Cairo, GtkGLArea [gnome.org]
and the list goes on
I'll gallop with you further if you want.
Re: (Score:3)
How is a Wine app on a GTK+ system any less "native" than a Qt app on a GTK+ system? It's literally just a different set of userspace libraries.
Not quite, though.
Most of those userspace libraries are emulating behavior that isn't well defined and translating behavior with a *very* thick compatibility layer encompassing *literally* every single aspect of a program's interaction capabilities.
Wine isn't implemented as a personality within the kernel to interact directly with native primitives, nor is X running a GDI subsystem.
Ultimately, I guess what is native then?
I suppose it's shades of gray. One could argue, I suppose, that qemu binary cross-
Re: (Score:2)
Ultimately, I guess what is native then?
I personally would draw one line between Wine ("Wine is not an emulator") and a same-architecture VMM such as VirtualBox and another line between a same-architecture VMM and an actual emulator.
Re: (Score:2)
I personally would draw one line between Wine ("Wine is not an emulator") and a same-architecture VMM such as VirtualBox
Why, though?
If we're going to be arbitrarily arbitrary, we can say that KVM is just another set of userspace libraries, with a thick translation layer between the application and the host kernel.
and another line between a same-architecture VMM and an actual emulator.
Why, though?
qemu is capable of fully emulating an x86 binary and interfacing it directly with the host OS. It's basically just an ELF loader, and a translation layer.
I'm not arguing that you're wrong, by any means, just that I think it's a bit disingenuous to say that a toolkit library such as GTK or Qt are equi
Re: (Score:2)
You're correct that paravirtualization [wikipedia.org], which modifies the kernel to accept a simplified machine model presented by the VMM, blurs these lines. But historically, publishers of proprietary operating systems have been hostile toward production use thereof as a guest under paravirtualization.
The other big differences:
1. Wine is $119.99 cheaper than Windows in a VM. It'd be technically possible to automatically provision a VM on the user's machine on demand, but I doubt that Valve would want the legal hassle as
Re: (Score:2)
The other big differences:
Oh I really don't disagree with the use of Wine at all. I think it's fantastic that some Big Money is picking it up to help those guys out. Their job is horridly complex (emulating a more or less undocumented API, with a black box implementation) and it's a miracle it works at all. I've used Wine for many years.
Being this is happening with Steam, which is a large enough distribution platform that developers actually pay it attention- we may see Windows apps even targeted for Wine compatibility... which is
Clothes vs a giraffe costume (Score:5, Insightful)
Your clothes are a layer between your skin and people observing you.
A giraffe costume is a layer between your skin and people observing you.
Your clothes are made to fit you. They don't hide your shape or size, or make you look like something other than what you are. They are a natural fit to a human of your size and shape. They don't get in the way of using your hands and mouth, the interfaces you are designed to work with.
An giraffe costume isn't a natural fit for you, and it hides your actual size and shape. it gets in the way of using your hands and mouth naturally. It's awkward, and definitely not what you want to wear while running a race, because it slows you down.
Wine is a Windows costume for Linux, to make Linux look kinda like Windows. Rather than exposing the Linux interfaces in an organized, easy to use way as GTK does, it hides the Linux interfaces the same way a giraffe costume hides your mouth, and the result is muffled communication. GTK is designed for Linux, to fit properly on Linux, the same way your clothes are designed to fit properly on your body.
Clothes hide your shape (Score:2)
Your clothes are made to fit you.
That depends to an extent on whether you saw a tailor or bought off the rack.
They don't hide your shape or size
With exceptions. For the past several decades, a lot of money in the fashion industry has gone toward hiding the overweight brought on by the modern American diet. The loose clothing commonly associated with the Middle East hides the shape of the body for two reasons: as a side effect of "chimney effect" convective cooling design for hot weather [theguardian.com] and (allegedly) to distract the brain from sexual desire. The loose ankle-length vestme
Re: (Score:2, Funny)
You're thinking of GIMP ;P
Re: (Score:2)
How is a Wine app on a GTK+ system any less "native" than a Qt app on a GTK+ system?
Got to correct you there, you're a bit unclear on how these stack. Qt apps never link to GTK+ libraries. Both Qt and GTK+ sit on top of a window manager, to which they link, in addition to many other low level libraries such as Xlib.
Wine sits on top of a window manager (Score:2)
Qt apps never link to GTK+ libraries. Both Qt and GTK+ sit on top of a window manager, to which they link, in addition to many other low level libraries such as Xlib.
Likewise, Wine sits on top of a window manager, to which it links, in addition to many other low level libraries such as Xlib. In my mind, this makes Wine a widget set, little different from Qt or GNUstep.
Re: (Score:2)
Wine implements the entire Windows ABI, a bit more than a widget set.
Re: (Score:2)
Got to correct you there, you're a bit unclear on how these stack. Qt apps never link to GTK+ libraries. Both Qt and GTK+ sit on top of a window manager, to which they link, in addition to many other low level libraries such as Xlib.
Ah, but what of QGtkStyle [wikipedia.org], a part of Qt since Qt 4.5? It uses GTK+ to draw GUI elements for Qt applications, thereby making them look [somewhat] like GTK+ applications (save for the excessive whitespace that seems to appear in all Qt apps.) There is a corresponding equivalent for going the other direction as well, but I can't recall its name at the moment and it's not directly relevant to the conversation anyhow...
Re: (Score:2)
In your example, Qt apps still don't link to GTK.
Re: (Score:2)
because a Linux binary is native to the Operating system, which is at a lower level than being native to the desktop environment. QT and GTK apps on a Linux system are both Linux native applications, Wine apps, are not.
Wine vs. ld-linux.so.2 (Score:2)
Different people have different opinions on the philosophical question of what an operating system comprises. As long as defining "operating system" is hard, defining "native" will also be hard. These questions should help determine where one might draw the line:
Is an executable loader part of "the operating system"? In Linux, executable loaders are not part of the kernel except in the special case of a statically linked ELF. Everything else, such as Wine's PE format or an ELF that uses a shared library, go
Re: (Score:2)
That and relying on the DirectX API.
Re: (Score:2)
And go look up, what Wine actually is. Hint: A shitload of translations from shitty quirky and even ancient toy OS APIs, to make toys run on a real OS.
And I've seen people who describe Qt as a "toy" environment, and others who describe GTK+ as a "toy" environment.
Re: (Score:2)
I remember the days before we had good toolkit libraries though. Thank god for Qt and GTK.
Re: (Score:2)
Also, is this some kind of secret advertisement for Qt?
No. I'm just stating the view that Wine is a UI toolkit with a PE loader. Just as LessTif reimplements Motif API and GNUstep reimplements Cocoa API, Wine reimplements Win32 API. This makes it in theory no less native than any other UI toolkit that your desktop environment happens not to use.
- If you run a KDE Plasma desktop environment, apps using GTK+, Motif, or GNUstep are just as non-native as apps using Wine.
- If you run GNOME, MATE, Cinnamon, Xfce, or LXDE, apps using Qt, Motif, or GNUstep are just as
Re: (Score:2)
Cocoa is the new name for OpenStep. What you're saying is as if macOS were substantially different from OS X.
GIO, GLib threads, etc. (Score:2)
GTK+ is also "a translation layer" that takes GTK+ calls and maps them onto Xlib. It also has some "quite complex logic", such as the GIO sitting on top of the Linux file system and network interfaces. And just as Wine maps Windows threads onto POSIX threads, GLib provides GLib threads [gnome.org] that map onto POSIX threads (under Linux) or Windows threads (under Windows).
Re: (Score:2)
One, AFAIK Qt apps aren't "on" a GTK+ system, so I'm not sure on what you're trying to drive at here.
I have used the name "GTK+ apps on a Qt system" to describe the result of the following steps:
1. Install Kubuntu or any other KDE Plasma distribution on a PC.
2. Discover that Krita doesn't do indexed color and install GIMP through the distribution's package manager.
I have used the name "Qt apps on a GTK+ system" to describe the result of the following steps:
1. Install Ubuntu, Xubuntu, Linux Mint, or any other GNOME 3, Xfce, or Cinnamon distribution on a PC.
2. Discover that GIMP doesn't do adjustment layers
Then call it "installing a Wine app" (Score:2)
Installing a GTK+ app or installing a Qt app.
If an app's developer or distributor explicitly supports use of the app in Wine, you can add "installing a Wine app" to that list. The featured article is about a distributor adding such support.
Not only am I fairly sure that's now how the software stack looks so the latter may not exist/disappear and the software can still function
Likewise, Wine's GDI is flexible enough [winehq.org] to be adapted to Wayland or other non-X graphics stacks.
Does it really matter if they ignore native Linux (Score:2)
Re: (Score:2)
Hopefully this doesn't give companies an excuse to ignore native Linux development.
The opposite actually. It gives game developers confidence that the Linux game market is real and here to stay. And that it is likely to undergo rapid expansion. Obviously, we prefer native ports.
Re: (Score:2)
Re: (Score:3)
It's a great excuse actually. When you create a Windows game, you create it for at most three platforms (Windows 7, 8 and 10.1 which largely have the same behavior, same APIs, same ABIs, same libraries; sans Direct3D 12 which is exclusive to Windows 10).
When you create a game for Linux you have to target a billion of platforms [altervista.org]. Let game devs target Windows and test if the game properly runs under Wine/Proton - that would be enough.
Re: (Score:2)
dead os like Linux.
LMAO! Wait, wait wait, wait wait wait. Say that again. Ooooh. Too funny. Linux. Runs on more devices than any other OS. But. It's dead. Shah. OK. Drink more koolaid.
Linux is widely used, X11/Linux not quite so much (Score:3)
The featured article is about Steam. "Linux" in the context of Steam implies a userland environment that can run applications that use Steam Runtime [github.com]. This means X11/Linux on an x86-64 desktop or laptop computer, not Android or router firmware or server operating systems.
Re: (Score:2)
I run SteamOS on my router, you insensitive clod!
Re: (Score:2)
By that logic, Microsoft Office is a Linux program too.
In the sense that it's certified by its publisher to work under Wine?
Re: (Score:2)
For some of the games, they seem like wrapped Playstation, XBox and even DOS games with Windows "mannerism", wrapping themselves alongside a 'shoddy' keyboard/ controller interface, that may or may not break during the next Steam update.
Perhaps running on Linux will bring new issues, but it may fix others such as Windows dialogs taking focus away from your games and asking you the same question over and over, despite checking the box that says "Never
Re: (Score:2)
I do not expect any serious game publisher making AAA games to consider NATIVE Linux development to be even a "nice-to-have"
But.. what about the PS4? PS4's are BSD systems. If there's a PS4 build then doing a Linux build shouldn't be a too major of an undertaking.
Re: (Score:2)
I use looking Glass to pass my Titan Xp though to a kvm copy if Win 10 Enterprise.
Works well.
What about VAC and other anti-cheat?
This might be the dealbreaker for me (Score:2, Interesting)
Iâ(TM)ve been flirting with Linux for years, but using windows only because most games donâ(TM)t run on it. If this works and works well, iâ(TM)ll probably switch
Re:This might be the dealbreaker for me (Score:5, Funny)
And as a bonus, your apostrophes will work!
Re: (Score:2)
My GF just game me her old laptop because it was slow and the battery was dead. I spent $25 on a battery and put Mint on there as my first dedicated linux computer. I installed a windows VM on it just in case, and so far I haven't had to touch it. Mint is rather easy to switch to, and it plays windows games on Wine better than I expected.
It's definitely worth a try if you've got spare hardware handy.
BSD version (Score:2)
Good strategy for Steam. (Score:5, Informative)
A game box with Linux will be far more useful, and likely to be on more than a couple of times a week.
Re: (Score:2)
As one with a dedicated game machine that was never going to update to Windows 10, this is a very positive outcome. A game box with Linux will be far more useful, and likely to be on more than a couple of times a week.
Good news for me. I've replaced a couple components in my pc recently, and since I bought an OEM copy of Windows 7 years back when I first built it, it now shows as "not genuine". My HDD was also failing so I bought a new one on the cheap. I was planning to upgrade my PC later this year with a new processor but was worried I would have to upgrade to windows 10, because basically all I use it for is gaming. If Steam can now run most of it's games on Linux, I'll just bite the $40 bullet, keep the good HDD
Re: (Score:2)
I intend to run the same Steam games on both (dual boot) and keep my options open.
Of course, Steam must have done some of their own. They likely would not be doing this otherwise.
Re: (Score:2)
no benchmarks have been published yet, even though valve acknowledges that there will be an impact, there are also a lot of games where this will be a no-issue or barely noticable.
Game Changer (Score:2)
Side comment (Score:5, Insightful)
I just think it's a thing of beauty what Valve has been doing for Linux gaming this past decade.
With Windows 10 going to a subscription/ad model.. (Score:2)
This is perfect for me. There is literally no reason for me to run windows except for games these days so this is great news.
Has anyone had experience with it that can comment on the performance?
Why not Mac? (Score:2)
They explicitly say in the FAQ that while Wine and Proton work on Mac, they have no plans to support the Mac at this time - I wonder why not? Maybe they worry about confusing people where games have a Mac version but they could also run the Windows version via Proton...
Re:Why not Mac? (Score:4, Insightful)
Re: (Score:2)
That's a pretty ignorant statement, when you look at how many Macs were sold in the last decade or so, and are in active use.
Sure, I have no doubt Apple and Valve/Steam have butted heads over how to handle online sales. Apple has an online store, after all. But open source that you can compile and run inside OS X is somewhat immune to Apple's whims. Yeah, they might have a graphics API that's unique -- but that can be worked around (MoltenVK). The OS is Unix based, though, and should really require less so
A lesson learned from GoG (Score:2)
Re:A lesson learned from GoG (Score:4, Insightful)
MOAR (Score:2)
This is exciting news! Any word on VR games?
Re: (Score:2)
I didn't RTFA until I posted like a newb, the first compatible game they list is BeatSaber!
Good for linux gaming (Score:5, Insightful)
Some Linux diehards will say this is a backwards step because they think developers should make native games, and they worry that this will cause developers to get lazy and not bother building for anything but Windows.
But this is actually a good move by Valve. I've been tracking Linux games for a long time, and the rate of Linux game releases has flat-lined over the last two years. Initially Linux was gaining ground on Windows, in fact by mid-2016 Linux as a % of all games on Steam had reached the giddy height of 25.5% - there were 9000 Windows games and 2300 Linux games. Since then Linux has been losing ground again. The rate of new Linux games has been a virtually flat linear growth of ~100 new games a month. My conclusion from this is that the developers willing to make Linux releases are already doing so, and the rest aren't likely to. In contrast, Windows (and Mac) continued to show accelerating growth, pulling away again from Linux's linear growth. Some attribute this to the explosion of Windows gaming in China, and others attribute this to a boom in Windows shovelware. Regardless of the reason, only 20% of all games on Steam nowadays have a Linux version - next month we'll see the milestones of 5000 Linux games and 25,000 Windows games respectively
I believe Valve also noticed this trend two years ago and drew the same conclusion. I don't think it's a coincidence that all the Vulkan / Wine / DXVK work started then. It's a chicken-and-egg dilemma. They had already reached saturation in winning over developers to support Linux, and now they need to win more users. With more users will come another opportunity to win over more developers.
So yes, this is a good thing for Linux gaming.
Re: (Score:2)
"Some Linux diehards will say this is a backwards step because they think developers should make native games, and they worry that this will cause developers to get lazy and not bother building for anything but Windows."
Theres some truth in this statement but I welcome the renewed push to get more games working on Linux. Remember that Steam is the foremost digital games distribution platform and therefore carries a lot of weight. This presumably will invigorate SteamOS usage more and with it an increased us
Re: (Score:2)
Some Linux diehards will say this is a backwards step because they think developers should make native games
They ought to, especially if they already have a PS4 version. After all, PS4's are BSD machines, so some of the work has already been done.
Re: (Score:2)
Some Linux diehards will say this is a backwards step because they think developers should make native games, and they worry that this will cause developers to get lazy and not bother building for anything but Windows.
But this is actually a good move by Valve. I've been tracking Linux games for a long time, and the rate of Linux game releases has flat-lined over the last two years. Initially Linux was gaining ground on Windows, in fact by mid-2016 Linux as a % of all games on Steam had reached the giddy height of 25.5% - there were 9000 Windows games and 2300 Linux games. Since then Linux has been losing ground again. The rate of new Linux games has been a virtually flat linear growth of ~100 new games a month. My conclusion from this is that the developers willing to make Linux releases are already doing so, and the rest aren't likely to. In contrast, Windows (and Mac) continued to show accelerating growth, pulling away again from Linux's linear growth. Some attribute this to the explosion of Windows gaming in China, and others attribute this to a boom in Windows shovelware. Regardless of the reason, only 20% of all games on Steam nowadays have a Linux version - next month we'll see the milestones of 5000 Linux games and 25,000 Windows games respectively
I believe Valve also noticed this trend two years ago and drew the same conclusion. I don't think it's a coincidence that all the Vulkan / Wine / DXVK work started then. It's a chicken-and-egg dilemma. They had already reached saturation in winning over developers to support Linux, and now they need to win more users. With more users will come another opportunity to win over more developers.
So yes, this is a good thing for Linux gaming.
Developers should make native Linux games.
But to get that happening you need people to be gaming on Linux. So using a stopgap measure like running Windows games through WINE or some other system is the way you get gamers to Linux. The truth is I hate Windows, we all hate Windows but I love games, I love games more than I hate Windows so I end up using Windows.
If you can get the numbers to Linux, the games will come.
OMG... (Score:5, Insightful)
Games are literally the last bastion for Windows.... this is huge and Valve deserves our thanks.
Re: (Score:2)
Corporations around the world take issue with your statement.
Can Wine run a custom mission critical sharepoint script?
Re: (Score:3, Insightful)
if your mission requires a sharepoint script then it isn't a very critical mission
Re: (Score:2)
if your mission requires a sharepoint script then it isn't a very critical mission
Don't underestimate the stupidity of a multinational.
Re: (Score:2)
not a windows guy, but sharepoint script run in... the browser?
i never had a problem with sharepoint on linux so far.
Re: (Score:2)
i never had a problem with sharepoint on linux so far.
And yet many of sharepoints functions don't even work properly even in Edge let alone anything other than IE. Don't underestimate the ability for corporations to find stupid edge cases and then implement them everywhere.
OMG^2 (Score:2)
If someone still uses sharepoint, he have no idea what is doing nor why, he just throw some money to a problem and hope it solved it. If it is mission critical, it should never use sharepoint !
Re: (Score:2)
If someone still uses sharepoint, he have no idea what is doing nor why, he just throw some money to a problem and hope it solved it. If it is mission critical, it should never use sharepoint !
You've never worked in a large company have you. Protip: check your logic in at the door and report to lobotimization, we will issue you your building pass when you have drooled sufficiently from the process and your eyes show no more signs of life.
Re: (Score:2)
Re: (Score:3)
you mean MS Office - there is still no usable alternative for Linux - just some free half-baked toys for people who never needed an office suite in the first place
- Most people who use MS Office have no need of an office suite - they would do fine with a simple word processor and calculator
- For typing a letter, making a simple graph or presentation, etc, libreoffice is fine.
- Google docs/calc/etc offers a decent set of tools. It's missing a lot of features, but the collaboration features are fantastic. A lot of my work doesn't really need complicated type setting and reference management, and google docs makes it a lot easier to share things
- The CSV import/export i
Re:OMG... (Score:4, Insightful)
for 99% of home users LibreOffice offers all they need.
we're talking games here, so corporate use was never part of the discussion.
Re: (Score:2)
for 99% of home users LibreOffice offers all they need.
The fact is that for 99% of business users, the same is true. Even most of them are not using any of the obscure features of Microsoft Office that LO hasn't got. The only real exception is access databases, which should all be killed with fire anyway.
Re: (Score:2)
For 99% of home users, Google Docs is all they even need.
Got my wife a Chromebook (Acer C720) almost 5 years ago. The only thing she's ever missed from Office was the ability to electronically sign a PDF, which isn't something MS Office can do anyway.
Re: (Score:2)
LibreOffice do replace Ms Office for most people... Usually people hate the change because of usage habit, but it do replace without any problem... for those that do not replace, they can still use MS Office in linux, either via wine or just like in windows, via a browser in Office 365
So yes, you can use MS Office in linux if you really want to, it is again a usage habit problem
OS/2 run windows better then windows so few os/2 (Score:3)
OS/2 run windows better then windows so few real os/2 apps where made and then windows got updates that did not work any more with OS/2 windows.
It will be nice have Linux games that are not tied to windows API's windows 10 is free and auto updates so can just up date our API's in a way that makes it not work on wine.
Re: (Score:2)
I think Valve wants Linux/SteamOS to succeed, or at least they want it to be more successful then it is currently. A lot of people claim not to make the move because game X is not available on Linux.
This excuse won't be valid anymore.
Ownership of games on Steam? (Score:2)
Re: (Score:3)
Name any modern game that you own?
Almost all of them are Internet-dependent, with servers run by the software manufacturers, that stop receiving updates after a few years.
But I've have 1000 games on my account for... 14 years now? That's a better ratio than the number of games I owned in the DOS days whose disks still work or which I can get running on a modern machine.
You're using the same argument as people did 14 years ago. The answer's still the same and well-publicised. Nobody really knows, but Stea
Re: (Score:2)
While most of the games have the Steam DRM, some do not, as long you download then, you can play then without any problem.
If steam goes out of business, it should probably release a "permanent" DRM update, so users could still play installed games offline.
But do not worry, checking the profits per workers, valve have higher profits than apple, it is one of the most successful companies out there
Better compatibility than Windows... (Score:2, Interesting)
...for older games. I've tried many old windows games that no longer work in the later versions of windows, but work out of the box in Steam Play on Linux. So for classic gaming, Steam Play on Linux could become the platform of choice. Some of the games have been removed from the steam store because they no longer work in Windows. It would be funny if they were added back to the store as Linux only games after this is out of beta.
Tested out Star Trek Online (Score:2)
When STO went free to play, I started playing it on Linux. (though I was hoping for an eventual PS3/PS4 version). It performed okay, but as time went on, the performance suffered. And then Cryptic did a major update which pretty much prevented STO from running on Wine unless you compiled a bleeding edge wine install and engaged in the usual travails of getting it to work. I basically had to quit the game as a Captain 35.
I installed it via steamplay on my Fedora machine and it "just worked", though I have
Re: (Score:2)
I have been playing the past few months with wine staging just fine, before Valve added wine themselves.
Probably at some point wine fixed the issues you were having. About two years ago i found a problem playing the game as well, but did try again some months later and it worked, especially when they changed the launcher and no longer showed that other Heroes game.
Wine, Whine, Linux users never will be satisfied (Score:2)
Hardly a word of praise for Valve/Steam for saying "we're tired of waiting for devs to get on board with linux support". Instead, the inevitable debate about how Wine is better, overlooking the work it takes to keep a game working in Wine long term. Linux users have bemoaned the lack of games on the platform, give them games and they bemoan the delivery method too. If you can't do it from the command line, it's just not "real" linux i guess.
good idea, not too stable yet (Score:2)
I tried it with two games so far.
Cold Waters worked - of sorts (no fonts in the ingame UI at all, sounds distorted - unplayable)
OFP: Red River - didn't even launch.
I like the idea, but so far I'll stick to rebooting to "that other OS".
Re: (Score:2)
they are only starting this, only a few games where checked. With time more requested games that fail to work will be picked up by valve and fix any wine issue or create the correct set of wine options... slowly those errors will disappear ...
of course, not all games will work, but most will
Good for HumbleBundles... but still cautious (Score:2)
I have bought many Humble Bundles over the years, and while there have been a lot of games available for Linux, there have been quite a few "steam/windows only" games that I haven't been able to play. My kids' computers run Win7. I have been disappointed that more and more games in bundles are "steam-only" instead of DRM-free like in the beginning. For the most part because my kids all use my steam account because that is what the games are linked to. But there are challenges with that approach (one log
Re:A better replacement for Wine? (Score:5, Informative)
Not in that general of a sense, no. It is still Wine but now with significant resources invested in gaming-specific technologies.
Re:Upstreaming (Score:5, Informative)
All changes are upstreamed to the Wine project as they said in their FAQ, located here: https://store.steampowered.com... [steampowered.com] internally it's their packaged version with changes for Steam specific support but otherwise just Wine. Open source, and sources here: https://github.com/ValveSoftwa... [github.com]
Re: (Score:2)