Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

In a recent update to the Linux Steam Client, the ability to run Linux games inside a special container was added in. At the FOSDEM event, Collabora consultant Simon McVittie who works on helping Valve with the Linux steam-runtime gave a talk on it.

The talk goes over a brief bit of history on the different versions of the steam-runtime, which is definitely interesting for any developers looking at Linux support and for gamers who perhaps don't entirely understand much about it. This includes the problems with it and from there they go into info about "pressure-vessel", the new and experimental Container system.

Hilariously, Steam pops-up during the presentation asking McVittie to update. See the full video below:

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link

We've heard so many times on how the fragmentation of Linux distributions causes issues for game developers, and while I'm no game developer and not knowledgeable enough on the internals of Linux and game dependencies to properly comment on that I do think it's fantastic that Valve funds attempts to make Linux gaming better in so many ways like this. Obviously a big hat tip to all the people at Collabora too, some really smart people working there.

A more up to date runtime code-named "Soldier" seems to be in testing, with the pressure-vessel container opening up options on this with it being a lot more flexible, so older games can keep an older runtime in the container with newer games using the newer runtime again in a container. Certainly sounds like the future of Linux gaming will be interesting.

There's more Linux videos up from Collabora which you can see listed on their website here.

Article taken from
Tags: Steam, Video
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
Page: «3/3
  Go to:

elmapul 25 Feb, 2020
Quoting: Guest
Quoting: elmapul
Quoting: Liam Dawe
Quoting: elmapulthings like this make me want to give up developing for linux...
Ah yes: Developers try to make things easier to deploy across all distributions.

You: I give up.

Makes sense.

first off, if that is the easier way that they are proposing, i cant imagine how hard it was before, plus i cant afford to run that solution, containers will dry out my limited performance.

second, valve supposedly solved this issue already, why do we still need this solution?

either its impossible to solve it once and forever, or it dont worth the performance cost.

in any case, i dont like how it sounds, the way things are, looks like someone is causing problems to sell the solution.
as they say, when the service is free, you are the product, with so many distros breaking backward compatibility with then selves or evolving into different directions that cause problems to support all of then without standards and clear benefits to that fragmentaiton, the only thing i can think off is that its sabotage, really.

its just ridiculous that we had 4 different browser engines (gecko, trident, presto, webkit) and things just worked in all of then. (nowadays, most browsers just use webkit/bink, because its cheaper than continuing developing their own code base, not because things broke all the time) if even microsoft could agree to follow some standards (web standards) there is no reason why the opensource world has to be that mess.

and before any one say that browsers arent as complex as an operating system, we can run entire operating systems inside one browser, there is no excuse.

So Valve never solved the issue, they just pushed the more difficult problems a bit further down the line. All the issues being seen right now were apparent when Valve took their Runtime route, but they had to try something.

Desktop development is a moving target. Libraries are updated, glibc gets updated, kernel gets updated, etc. Sometimes the ABI for some library changes, and any game that relies on it also breaks. Games suffer more visibly from this because so many of them are proprietary binaries, whereas the majority of software in a distro is actually open source and be simply recompiled to fix some breakage, or patched easily to fix others.

And while a Good(tm) developer can minimise risk of breakage, properly package their games, keep dependencies to a minimal, that's actually an increased barrier to development that is not desirable. There's no easy way to bundle games on a GNU/Linux system for those not as familiar with it, and guarantee that the game won't break on a whim in a couple years.

Web standards are completely different to library dependencies. I would suggest that's not a good analogy.

great, lets just shift the blame, its not the operating system fault that all aplications stop working after an update, its the applications fault that they didnt future prof then selves against whatever bullshit was in the mind of the os vendor when he issued the update patch.
i wonder what is the point of an operating system by that point.

not to mention that if we accept things like that, why would canonical change their behavior or anyone else? just break it and shift the blame to some one else, its definitely not our responsability.

i can agree that the aplication developers are responsible to some extent but they arent the only responsible for it, an good operating system should make sure that the aplications work for as long as its possible, otherwise the "good" developers will waste their time fixing stuff that shouldnt have broke instead of adding new features and fixing the bugs created by then instead of some thirdyparty.

" because so many of them are proprietary binaries" many open source games stoped working after some updates in the past, some times for stupid reasons like
"dependence x version 2.8.3 changed the name for 2.8.4"
being proprietary has nothing to do with it.

". There's no easy way to bundle games on a GNU/Linux system for those not as familiar with it, "
well, package managers were created, among other things, to stop aplications from distributing their own depencences, duplicating the used space on disk, looks like it was pointless since we are doing it anyway to solve the issues caused by package managers and the complete lack of standards of what comes included with an distribution and what not.
not to mention that we have 1% of the marketshare on the desktop, and deskop is just 1/3 of the incoming of an game (i'm not including mobile games here, they are an different type of game)
then we have to support one thounsand distributions and the end user will send us (or the solution on google, for) an error message in the system languague that they use, instead of english.
combine all that with problems that only occur in certain software, and you explain why almost no one codes/uses for linux.

that is why, we cant put the full blame on the aplication developers, they are the weakest link in the chain.
users can simply change the software, or the operating system (go back to windows)
companies like canonical dont give a fuck about desktop anymore, their money come from companies, especialy big ones like pixar.
so who will be the scapegoat the and be blamed when things stop working?
gradyvuckovic 15 Sep, 2020
I think it's fair to say it's the responsibility of developers to ensure that their software works on the platforms they claim to support when they ship their software.

But if those supported platforms then change and break that software, I blame those platforms.

If for example a game developer made a Playstation game, released it, and the game worked flawlessly, then 5 years later Sony updated the Playstation console OS and it broke that game, I would say it's Sony's fault, not the original developer.

Because while it's all well and good to say 'Well developers should just update their software' or make things 'future proof', games are a great example of why that isn't always practical. In some cases the original developers who developed some of the games which are still being played today on Steam aren't even still around, and the source code might have even been lost. A developer can't keep updating software forever, platforms need to be designed to handle that.

Platforms should strive to offer a stationary target for developers to develop software against. If changes are to be introduced, that should become a new target, and those changes shouldn't affect software being developed against the old target.

This is why Flatpak is a good system, it allows devs to target a runtime, make sure their software works for that runtime, then as long as that runtime continues to be available and supported into the future, even for decades, that software should still work, no matter how much Linux changes.

And users only have to download and install the runtimes they need for the software they're actually using. Ideally such a concept should become part of Linux desktop operating systems themselves, it would make life much easier for developers. Then Valve wouldn't need to come up with container solutions to keep old Linux games working on Steam.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.