Support us on Patreon
PayPal
Followers of the Penguin, Marcin Iwiński, one of the founders of CD Projekt RED, has spoken out about why the developer of The Witcher series and Cyberpunk 2077 has not yet shown any support towards Linux.
Citing an issue deemed a myth by many, especially by Ryan "Icculus" Gordon who took to busting this myth during the Steam Developer Days of 2014, Iwiński believes that if you are going to support Linux, you cannot simply pick one distribution to support. Instead, he feels that CD Projekt RED would have to take to supporting at least five.
Source (from 1:29:16).
There you have it. SteamOS will somehow negate having to support five Linux distributions and defeat the beast that is distro fragmentation once and for all.
How do you feel about CD Projekt RED's reasoning? Will SteamOS bring the desired changes? I, personally, can only keep on hoping and ask you kind folks to keep on voting for GOG, sister company to CD Projekt RED and reseller of its games, to finally add Linux support. Article taken from GamingOnLinux.com.
Citing an issue deemed a myth by many, especially by Ryan "Icculus" Gordon who took to busting this myth during the Steam Developer Days of 2014, Iwiński believes that if you are going to support Linux, you cannot simply pick one distribution to support. Instead, he feels that CD Projekt RED would have to take to supporting at least five.
Marcin Iwiński, CD Projekt REDFirst of all, we have a lot of respect for Steam and we think they are very, very good business guys and good gamer friendly guys and that's really, really important. We like what they are doing and with the Steam Box, if they will be able to deliver a cool console, definitely, we are interested in having a game there.
You know, one of the reasons we have not released The Witcher on Linux is that we most probably have to address five different versions of Linux and this is always terrible to support the quality of the games afterwards. The patches, the updates, and everything. If Steam will deliver a constant Linux environment, call it SteamOS or anything like that, we would love to have our games there because, you know, the more people play our games, the better for us.
Source (from 1:29:16).
There you have it. SteamOS will somehow negate having to support five Linux distributions and defeat the beast that is distro fragmentation once and for all.
How do you feel about CD Projekt RED's reasoning? Will SteamOS bring the desired changes? I, personally, can only keep on hoping and ask you kind folks to keep on voting for GOG, sister company to CD Projekt RED and reseller of its games, to finally add Linux support. Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
Good thing is that they did not outright say "no". At least they gave a reason, even if it's a dumb one.
The single best thing that Valve have done with bringing the steam client to Gnu/Linux is to pick a single distro and say that it will offer support on that distribution only (is it Ubuntu 12.04? I forget). By doing this, standards are introduced for any distro maker that wants to appeal to gamers. Introducing standards in this way negates the possibility of distro fragmentation causing problems to gamers.
There is no need to look to the future to wait and see if SteamOS will succeed because the Steam client has already nullified the problem that CD Projekt RED are stating exists.
Anyway, I would be happier if this was an actual announcement that Witcher 3 is definitely coming to Linux as I've loved the previous 2 games but have now cut all dependency on Microsoft software.
The cool things we get are driver support because Valve has the pull to nudge the likes of Intel, nVidia and AMD in the right direction and tools that were not previously available on Linux because nobody needed them that much, like the upcoming VOGL.
Hopefully, the companies involved, not just Valve, will realise that working together on production tools will help all of them to stay free of platform lock-in.
Didn't a lot of Windows games do the exact same thing? I haven't touched it since 2002, but back then I recall almost every game I had shipped with some version of DirectX, maybe the MSVC runtimes, VB runtimes, etc.
anyway send them this video ;):
View video on youtube.com
http://www.wykop.pl/link/1869416/eng-cd-projekt-red-rozwaza-wypuszczenie-wiedzmina-3-na-steamos/
Personally, I would rather people choose SteamOS as a standard than Ubuntu, as it is based on Debian and closer to upstream. Also, because it is gaming focused, it would be much better analyzed as a model for other distributions to follow in this regard.
That being said, most distributions already ship SDL as Gordon says, so that basically defeats the problem anyway, making this whole argument for the most part moot.
Maybe in game system requirements they should just say "requires at least SDL 2.x" like they used to say about DirectX back in the day?
Bring it on! *game face*
It is rather amusing, but if having Valve put together the needed libraries in SteamOS, rather than having to collect together the dependencies themselves, is what it takes to for some developers to be sensible about Linux... then we've got another thing to thank Valve for. I'm sure these guys aren't the only ones who need Valve's support as confidence-builder.
View cookie preferences.
Accept & Show Accept All & Don't show this again Direct Link
Come on, they have a legitimate reason for not supporting Linux. It's because no two distros are the same. Linux has no Standard API, No Standard API and shared libraries have caused dependency hell. You may say that modern Linux is more compatible with Wine is with ancient Windows Programs more than modern Windows. But Windows Programs from 1995 are more compatible with modern Windows than a Linux Binary from 1995 is with Modern Linux.
CD Projket RED is built on support and convenience, they draw a line in the sand and say what you need to run a binary and having video card specs, cpu specs and OS version is technical enough. any more technical like kernel, glibc, xorg, mesa, alsa and OpenGL versions is way too technical and makes things more inconvenient because most people don't know how to figure that out. The only Linux OS I see them supporting is SteamOS because it's standard because it's hard to support a lot of different distros with different places where libraries are located.
Perhaps you have never played with LD_LIBRARY_PATH and even chroots? Linux is actually quite backward compatible, thanks to Linus' policy about keeping userspace backward compatibility at the kernel level. For instance, on one contract I had to run some RHEL 2.1 apps 10 years later. LD_LIBRARY_PATH worked. Some GOL members are still running Linux binaries of NWN, which were released in 2003 (so over 10 years ago)
http://social.bioware.com/forum/1/topic/187/index/4643217
The main question with respect to providing binary-only games on Linux that will work for the next 10 years would be the quality of wayland backward compatibility support for old versions of opengl. There will probably be some less-accelerated fallback way to run it on the powerful future hardware, if needed. However, it's not like running 10 year old games is a sure thing on Windows either -- just today I was seeing complaints from a windows gamer fighting to get 4-yrs-old game working with modern Windows drivers.
Anyway, a distributor who set a goal of wanting their binary stuff to work on Linux for a long time would mainly just need to collect together the corresponding libraries and make the launcher use those libraries. It's not that bad for the developers, and totally convenient for the users.
That's the point of distributions.
No two graphics cards are the same. No two keyboards are the same. No two Mac systems are the same. No two Windows systems are the same.
All distributions are still binary-compatible with each other (provided you're not crossing hardware architecture boundaries; an ARM ELF won't run on an x86 system, yeah)
You keep using that word. I do not think it means what you think it means.
https://en.wikipedia.org/wiki/API
Linux implements several APIs, like big subsets of POSIX.
There's also the LSB ABI most distributions provide.
Libraries on POSIX systems are actually handled way more dependency-friendly than on Windows. You know, since they are uniquely numbered, and you can have different versions of libraries installed on your system at the same time, and the dynamic linker finds them automagically.
Shared libraries on Windows never worked well. There was never a standard system to manage different versions of the same library. There was never a way for a program request a minimum version. Or a central place where an application could register which version it installs, and deinstall it again without breaking other applications using the same library. As such, the only solution Windows ever had was to just for programs to bring all their libraries with them, installing them into their own path. Each minor version of DirectX installs their own support library for finding and connecting the different DirectX DLLs.
And guess what, if you want to ship a Linux game with all its required libraries, you can still do that as well. In comparison to Windows, Linux has a better solutions at hand, and still supports the only clunky solution Windows has regardless.
We've been around this same fucking issue the last time. You are talking bollocks. Woodruff and the Schnibble of Azimuth won't run on modern Windows systems. Urban Runner won't run on modern Windows systems. While many Linux binaries will still run on modern Linux systems.
Old Windows games have a big track record of not running on modern systems. That's why ScummVM exists. That's why ResidualVM exists.
Hell, that's why a big part of why GOG exists.
This is literally nonsensical gobbligook. Stop before you embarrass yourself further.
You don't need to know which kernel version you're running for a simple user application.
You don't need to know the glibc version, provided the person who compiled the binary did 5 minutes of googling to check that they are not using the latest beta-branch (and yes, there were a few faulty/buggy glibc versions in the past, but mistakes happen; the very simple fix is a recompile away).
You don't need to know which ALSA version you're running. Never did, never will. Hell, I never even cared and never knew, and I wrote code that directly called the ALSA API.
The Xorg version is also completely irrelevant to what applications you can run. Again, I don't know which version I run (I'm only vaguely aware that there was a renumbering after the XFree86 to Xorg change, something from 0.7.x to 1.x?), and I wrote code doing direct X calls. Creating windows, handling signals, drawing pixels, lines and circles. Good old days. :)
You do kinda need to know which OpenGL version your graphics card and drivers support, yes, if the game is dead-set on wanting a certain minimum version. Just like you need to know which DirectX version you can do. Interestingly, converting a "Won't run" to a "Will run" is often just a drivers update away, not even a full reboot required. Contrast that with DirectX 10 never working on Windows XP.
Saying "We support SteamOS" is no different than saying "We support Debian". Or saying "We support Ubuntu". Or hell, "We support Linux".
This has been a solved problem 30 years ago.
https://en.wikipedia.org/wiki/Dynamic_linker
A program does not need to know where the library is located. At all. In the linking stage of the compilation, the name (which includes the version number) and all used symbols are recorded in the ELF binary. When you run the program, the dynamic linker knows where it can look for the library (which is configurable, and every distribution provides defaults that fit with their layout) and will automatically find the library for you.
This even works when you use dlopen() to dynamically load a library:
https://en.wikipedia.org/wiki/Dynamic_loading
Well, to be charitable, he is probably trying to appear friendly to the developers, which in general is the best policy; spreading misinformation about how Linux works or how difficult it is to develop for serves no one, however.
this is for you too:
View video on youtube.com