Language Selection

English French German Italian Portuguese Spanish

Valve release an official statement about the future of Linux support, they "remain committed" to Linux gaming

Filed under
Gaming

After the recent upset caused by Canonical's plan to drop 32bit support in Ubuntu, then to turn around and change their plan due to the uproar caused by it, Valve now have a full statement out about their future support of Linux gaming.

Firstly, to get it out of the way, there's nothing to worry about here. Valve said they "remain committed to supporting Linux as a gaming platform", they're also "continuing to drive numerous driver and feature development efforts that we expect will help improve the gaming and desktop experience across all distributions" which they plan to talk more about later.

On the subject of Canonical's newer plan for Ubuntu 19.10 and onwards in regards to 32bit support, Valve said they're "not particularly excited about the removal of any existing functionality, but such a change to the plan is extremely welcome" and that it "seems likely that we will be able to continue to officially support Steam on Ubuntu".

Read more

Also: Steam Play updated as Proton 4.2-8 is out, DXVK also sees a new release with 1.2.3

Original and more coverage

  • Update on Steam, Ubuntu, and 32-bit support

    There has been a lot of news and discussion over the weekend on the topic of Steam on Linux and officially supported and recommended distributions. For those not in the loop, last week the Ubuntu project announced their intent to change how they're approaching 32-bit library support for future Ubuntu versions[discourse.ubuntu.com]. Following that announcement, we made a statement that Ubuntu 19.10 wouldn't be officially supported or recommended to our users going forward. As the Ubuntu project indicated, they let us know of their intent and walked us through the details earlier this month, which was much appreciated. We don't think it is unreasonable that they would want to take steps that are in the best interests of the project. That being said, we don't think it's an especially positive move for Steam and gaming-oriented customers who rely on this support.

    To provide some background, support for 32-bit libraries is required in order to run not only the Steam client, but also the thousands of games available on Steam that only support 32-bit environments. Enabling the Steam client to run in pure 64-bit environments, while feasible, would leave the vast majority of the current Steam library inaccessible to such users without an additional compatibility layer. Ensuring that all games a user owns remain fully playable wherever possible is a core principle of Steam, and we don't believe any solution that arbitrarily splits a user's library would be acceptable.

  • Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

    Following all the drama caused by Canonical announcing last week they'd stop their 32-bit archive with Ubuntu 19.10 and that leading to a mess of concerns including Valve saying they would not be officially supporting Ubuntu 19.10 and later, today they issued a statement reaffirming their commitment to Linux.

    Pierre-Loup Griffais, the longtime Valve Linux developer who last week said they would not be officially supporting Ubuntu 19.10 and later, penned a post on the Steam Community board today providing more insight and praising more distribution choices compared to when Steam on Linux first started.

Joey Sneddon's article about it

  • Valve Say Steam WILL Support Ubuntu 19.10

    Ubuntu gamers can breathe a sigh of relief as Valve has confirmed that Steam for Linux WILL support Ubuntu 19.10.

    Valve developer Pierre-Loup Griffais says Ubuntu’s recent rethink over plans to axe its i386/32-bit archive means it is “…likely that we will be able to continue to officially support Steam on Ubuntu.”

    Hurrah!

    The confirmation follows several days of high drama in the Linux Community, all resulting from Ubuntu’s initials plan to retire its 32-bit archive in the upcoming October release.

    It was that decision — which had been discussed by Ubuntu developers for some time — that stunned many. It resulted in a jaw-dropping tweet from a Valve developer, who announced that “Ubuntu 19.10 and future releases will not be officially supported by Steam or recommended to our users”.

Valve Now Says Steam Will “Likely” Support Ubuntu 19.10

  • Valve Now Says Steam Will “Likely” Support Ubuntu 19.10

    While Valve isn’t thrilled about Ubuntu’s likely plan to drop compatibility with legacy 32-bit software after Ubuntu 20.04 LTS, there are no immediate changes to announce. Linux gamers can keep using the next few releases of Ubuntu to run Steam’s library of games. The community has been heard.

Valve To Work With More Distros To Improve Linux Gaming

  • Valve To Work With More Distros To Improve Linux Gaming

    As a part of the ongoing Ubuntu-Steam spectacle, Valve has published a new update on their website. The Steam-maker company has reaffirmed its plans to continue to support Linux gamers and work with leading Linux distributions that are known to be popular among gamers.

    Starting with Ubuntu, Valve has confirmed that it will continue to support Steam officially on Ubuntu. “It seems likely that we will be able to continue to officially support Steam on Ubuntu,” Valve developer Pierre-Loup Griffais wrote in the update. This statement comes after Ubuntu decided to ditch its plans to retire the 32-bit packages starting with the upcoming Ubuntu 19.10 release.

Steam will to officially support Ubuntu

  • Steam will 'likely be able to continue' to officially support Ubuntu

    Earlier this week, Valve raised concerns around Ubuntu and Canonical’s plan to remove 32-bit software support. Valve said that it would need to drop support for the popular Linux distro if this happened and would need to begin recommending something else for users. Since then, Canonical has said that it will change plans and work to support certain 32-bit libraries based on community feedback, which means Valve will “likely be able to” continue supporting the OS.

    In an update post on the Steam for Linux discussion board, Valve’s Pierre Loup provided some background on the situation and talked about why dropping 32-bit support would be an issue. While Steam itself could run in pure 64-bit environments, removing 32-bit support entirely would “leave the vast majority of the current Steam library inaccessible” without an additional compatibility layer. Valve has been investigating ways to avoid 32-bit system dependencies within Steam for a while now but if 19.10 released without any 32-bit compatibility, Valve would need to “fully complete such a system in the 19.10 release time frame” and would require “fundamental change in Steam’s runtime environment”. The end result would have been a confusing and messy experience for end users.

Valve to continue Steam gaming on Ubuntu Linux

  • Valve to continue Steam gaming on Ubuntu Linux

    When Canonical announced that, beginning with October's Ubuntu 19.10 release, 32-bit -computer support would be dropped, it didn't expect there would be much blowback. It was wrong. Developers and users, especially of Steam games, threw fits. So, Canonical, makers of Ubuntu Linux, reversed course and asserted it wouldn't drop 32-bit software support in Ubuntu 19.10 and 20.04 LTS after all.

    So, everything's back to normal, yes? No.

    True, Valve will continue to support Ubuntu. But Ubuntu will no longer be called out as "as the best-supported path for desktop users." Instead, Valve is re-thinking how it wants to approach distribution support going forward. There are several distributions on the market today that offer a great gaming desktop experience such as Arch Linux, Manjaro, Pop!_OS, Fedora, and many others.

Canonical Backtracks On Pulling Of 32-bit Packages in Ubuntu

  • Canonical Backtracks On Pulling Of 32-bit Packages in Ubuntu Linux

    Last weekend, there was a huge uproar in the Linux community aimed towards Canonical and its decision to pull support for 32-bit libraries, after Ubuntu announced it would end support for 32-bit applications, starting with its next release.

    The decision was not well-received, especially by the gaming community, and Valve announced plans to drop support for Ubuntu in Steam.

    However, Canonical confirmed on Monday that following feedback from the community, it was clear that there is still a demand, and indeed a need for 32-bit binaries, and as such, it will provide “selected” builds for both Ubuntu 19.10 and the forthcoming Ubuntu 20.04.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

today's leftovers

  • Linux Weekly Roundup #35

    Hello and welcome to this week's Linux Roundup and what a wonderful week we had! We have plenty of Linux Distro releases and LibreOffice 6.3 RC1. The Linux distros with releases this week are Q4OS 3.8, SparkyLinux 5.8, Mageia 7.1, ArcoLinux 19.07.11, Deepin 15.11, ArchBang 2107-beta, Bluestar 5.2.1, Slackel 7.2 "Openbox" and Endeavour OS 2019.07.15. I looked at most of these Linux Distros, links below, I will look at some of them in the new week and some I will unfortunately not have a look at, for download links and more, please visit distrowatch.com Well, this is this week's Linux Roundup, thank you so much for your time! Have a great week!

  • Full Circle Magazine: Full Circle Weekly News #140
  • Christopher Allan Webber: ActivityPub Conf 2019

    That's right! We're hosting the first ever ActivityPub Conf. It's immediately following Rebooting Web of Trust in Prague. There's no admission fee to attend. (Relatedly, the conference is kind of being done on the cheap, because it is being funded by organizers who are themselves barely funded.) The venue, however, is quite cool: it's at the DOX Centre for Contemporary Art, which is itself exploring the ways the digital world is affecting our lives. If you plan on attending (and maybe also speaking), you should get in your application soon (see the flier for details). We've never done one of these, and we have no idea what the response will be like, so this is going to be a smaller gathering (about 40 people). In some ways, it will be somewhere between a conference and a gathering of people-who-are-interested-in-activitypub. As said in the flier, by attending, you are agreeing to the code of conduct, so be sure to read that.

Sysadmin Appreciation Day, IBM and Fedora

  • Gift ideas for Sysadmin Appreciation Day

    Sysadmin Appreciation Day is coming up this Friday, July 26. To help honor sysadmins everywhere, we want you to share your best gift ideas. What would be the best way a team member or customer could show their appreciation for you? As a sysadmin, what was the best gift you've ever received? We asked our writers the same question, and here are their answers: "Whilst working in the Ubuntu community on Edubuntu, I took it upon myself to develop the startup/shutdown sound scheme, which became the default in Ubuntu for, from what I can understand, the next decade. Whilst people had a love-hate relationship with my sound scheme, and rightly so, I had a love-hate relationship with my sound card during the development. At the time I had recorded all my sound samples using one sample rate, but my new sound card, as my motherboard had exploded a few days earlier, did not support it. I had two choices, resample all my samples (which I didn't really want to do) or buy a new sound card.

  • Red Hat OpenStack Platform with Red Hat Ceph Storage: Radosbench baseline performance evaluation

    Red Hat Ceph Storage is popular storage for Red Hat OpenStack Platform. Customers around the world run their hyperscale, production workloads on Red Hat Ceph Storage and Red Hat OpenStack Platform. This is driven by the high level of integration between Ceph storage and OpenStack private cloud platforms. With each release of both platforms, the level of integration has grown and performance and automation has increased. As the customer's storage and compute needs for footprints have grown, we have seen more interest towards running compute and storage as one unit and providing a hyperconverged infrastructure (HCI) layer based on OpenStack and Ceph. [...] Continuing the benchmarking series, in the next post you’ll learn performance insights of running multi-instance MySQL database on Red Hat OpenStack Platform and Red Hat Ceph Storage across decoupled and hyperconverged architectures. We’ll also compare results from a near-equal environment backed by all-flash cluster nodes.

  • The State of Java in Flathub

    For maintainers of Java-based applications in Flathub, it's worth noting that even if you consume the Latest OpenJDK extension in your application, users will not be broken by major updates because OpenJDK is bundled into your Flatpak. The implication of this for users is that they won't see updates to their Java version until the application maintainer rebuilds the application in Flathub. If you maintain a Java-based Flatpak application on Flathub, you can consume the latest version of your chosen OpenJDK stream (either LTS or Latest) simply by rebuilding; the latest version of that OpenJDK steam will be pulled in automatically.

  • Fedora Magazine: Contribute at the Fedora Test Week for kernel 5.2

    The kernel team is working on final integration for kernel 5.1. This version was just recently released, and will arrive soon in Fedora. This version has many security fixes included. As a result, the Fedora kernel and QA teams have organized a test week from Monday, Jul 22, 2019 through Monday, Jul 29, 2019. Refer to the wiki page for links to the test images you’ll need to participate. Read below for details.

Debian and Ubuntu Leftovers

  • Bootstrappable Debian BoF

    Greetings from DebConf 19 in Curitiba! Just a quick reminder that I will run a Bootstrappable Debian BoF on Tuesday 23rd, at 13.30 Brasilia time (which is 16.30 UTC, if I am not mistaken). If you are curious about bootstrappability in Debian, why do we want it and where we are right now, you are welcome to come in person if you are at DebCon or to follow the streaming.

  • Candy Tsai: Outreachy Week 6 – Week 7: Getting Code Merge

    You can’t overhear what others are doing or learn something about your colleagues through gossip over lunch break when working remotely. So after being stuck for quite a bit, terceiro suggested that we try pair programming. After our first remote pair programming session, I think there should be no difference in pair programming in person. We shared the same terminal, looked at the same code and discussed just like people standing side by side. Through our pair programming session, I found out that I had a bad habit. I didn’t run tests on my code that often, so when I had failing tests that didn’t fail before, I spent more time debugging than I should have. Pair programming gave insight to how others work and I think little improvements go a long way.

  • about your wiki page on I/O schedulers and BFQ
    Hi,
    this is basically to report outdated statements in your wiki page on
    I/O schedulers [1].
    
    The main problematic statement is that BFQ "...  is not ideal for
    devices with slow CPUs or high throughput I/O devices" because too
    heavy.  BFQ is definitely more sophisticated than any of the other I/O
    schedulers.  We have designed it that way to provide an incomparably
    better service quality, at a very low overhead.  As reported in [2],
    the execution time of BFQ on an old laptop CPU is 0.6 us per I/O
    event, against 0.2 us for mq-deadline (which is the lightest Linux I/O
    scheduler).
    
    To put these figures into context, BFQ proved to be so good for
    "devices with slow CPUs" that, e.g., Chromium OS migrated to BFQ a few
    months ago.  In particular, Google crew got convinced by a demo [3] I
    made for them, on one of the cheapest and slowest Chromebook on the
    market.  In the demo, a fast download is performed.  Without BFQ, the
    download makes the device completely unresponsive.  With BFQ, the
    device remains as responsive as if it was totally idle.
    
    As for the other part of the statement, "...  not ideal for ...  high
    throughput I/O devices", a few days ago I ran benchmarks (on Ubuntu)
    also with one of the fastest consumer-grade NVMe SSDs: a Samsung SSD
    970 PRO.  Results [4] can be summarized as follows.  Throughput with
    BFQ is about the same as with the other I/O schedulers (it couldn't be
    higher, because this kind of drives just wants the scheduler to stay
    as aside as possible, when it comes to throughput).  But, in the
    presence of writes as background workload, start-up times with BFQ are
    at least 16 times as low as with the other I/O schedulers.  In
    absolute terms, gnome-terminal starts in ~1.8 seconds with BFQ, while
    it takes at least 28.7 (!) seconds with the other I/O schedulers.
    Finally, only with BFQ, no frame gets lost in video-playing
    benchmarks.
    
    BFQ then provides other important benefits, such as from 5x to 10X
    throughput boost in multi-client server workloads [5].
    
    So, is there any chance that the outdated/wrong information on your
    wiki page [1] gets updated somehow?  If I may, I'd be glad to update
    it myself, after providing you with all the results you may ask.
    
    In addition, why doesn't Ubuntu too consider switching to BFQ as
    default I/O scheduler, for all drives that BFQ supports (namely all
    drives with a maximum speed not above ~500 KIOPS)?
    
    Looking forward to your feedback,
    Paolo
    
    
  • Should Ubuntu Use The BFQ I/O Scheduler?

    The BFQ I/O scheduler is working out fairly well these days as shown in our benchmarks. The Budget Fair Queueing scheduler supports both throughput and low-latency modes while working particularly well for consumer-grade hardware. Should the Ubuntu desktop be using BFQ by default? [...] But in addition to wanting to correct that Wiki information, Paolo pops the question of why doesn't Ubuntu switch to BFQ as the default I/O scheduler for supported drives. Though as of yet, no Ubuntu kernel developers have yet commented on the prospect of switching to BFQ.

Devices With Linux Support

  • Quest Releases KACE SDA & SMA Updates

    The update to 7.0 for KACE Systems Deployment Appliance is primarily about bringing a scope of endpoint management capabilities with new support for Linux devices to the table.

  • Rugged, Kaby Lake transport computer has a 10-port LAN switch with PoE

    Axiomtek’s Linux-ready “tBOX400-510-FL” transportation system has a 7th Gen Intel CPU and a 10-port managed switch with 8x M12-style 10/100Mbps PoE and 2x GbE ports. The rugged system also has 3x mini-PCIe slots and dual swappable SATA drives. Axiomtek has launched a fanless, Kaby Lake-U based transportation computer with a choice of power supplies designed for in-vehicle, marine, or railway applications. The rugged tBOX400-510-FL features a Qualcomm-driven, Layer 2 managed PoE switch with support for IP surveillance and video management applications. “Customers can connect IP cameras directly without installing an extra PoE switch, minimizing overall deployment costs and installation space onboard,” stated Axiomtek product manager Sharon Huang.