No, I am not mixing them up. The package formats were made to distribute binaries and sources. The package managers were made to manage binary versions and source versions and dependencies/conflicts. Zypper2 is not only a package manager, it does system configuration, snapshotting and a whole buch of stuff.
So like I said, they were all made to fit specific needs and business cases. I think you misread my response and what I was responding to.
why ask? just containerize everything and ask questions never
I know there’s container formats like snap, flatpak, appimage etc
But there’s also the proton approach, which is in effect a bundling of slightly older dependencies into a known environment - soldier, sniper, etc.
I am sure I saw a video where they do trickery around aliiasing or faking the glibc versions as well, but I can’t find it at present.
Here it is, but as I am new I can’t include links, so you’ll have to decode.
archive(dot)fosdem(dot)org/2020/schedule/event/containers_steam/
None of them are containers.
Soldier and Sniper are the Steam runtime which is not the same as Proton.
Proton is essentially a wrapper for Steam-integration around WINE, it doesn’t provide the runtime by itself. The runtimes are installed separately in steam and used in Proton, but they’re not the same thing.
This move is long overdue in my opinion. We have some progress with new pseudo-immutable distros and stuff like snap, flatpak, etc. But that’s miles away from a true containerized and portable OS. Old habits die hard. SUSE with ALP is certainly picking up on that container scent.
Zypper is great. Not the fastest, but all the extra juice zypper has…carefree experience. snapper saved my ass a lot of times 
I really want to see how Leap 16 changes things. Hopes are high. But I always increase my success by lowering expectations. But I can see myself spending some time getting into a different world. I gave Fedora Kinoite a try too (way different approach, I know) and Suse always gets a small fanboy-bonus just by my history in dealing with them.
It’s also a pita with shared libs, e.g. there is yet another openssl bug. We got openssl as dependency and multiple of our dependencies got it as dependency as well. So now we need to wait for all deps to use the fixed openssl version before we can use it.
Point being: it’s called dependency hell for a reason
Well it’s funny that on its own FAQ page flatpak uses the word container in various different ways to describe itself and similar technology.
flatpak(dot) org/faq/
You are just trying GUI play semantic games to make yourself feel powerful.
And, unlike you I’m actually trying to make a positive contribution instead of trolling.
And Valve refers to “steam runtime” as a container technology all over the place…
github(dot)com/ValveSoftware/steam-runtime
gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md
I fail to see how clarifying technical terms in a technical discussion on a tech forum is trolling, but OK?
Since you already refer to the FAQ, here’s an excerpt:
Is Flatpak a container technology?
[…] In general though we try to avoid using the term container when speaking about Flatpak as it tends to cause comparisons with Docker and rkt, comparisons which quickly stop making technical sense due to the very different problem spaces these technologies try to address. And thus we prefer using the term sandboxing.
OK it seems they work very different now then they used to so I’ll give you that one.
But then again we weren’t even talking about containers in the steam context in the first place? I simply pointed out that Proton and the runtime are 2 separate components, I didn’t even dispute anything about what you said.
If you feel personally attacked when someone disagrees with you or makes clarifications, maybe a public forum is not the right place for you?
flatpak and snap are containers, they use the same linux namespace features that other container systems also use for their process isolation and sandboxing.
Appimage afaik isn’t a container, it’s some kind of bundle like MacOS applications. It’s not running isolated from the rest of the system in any way. But I can be wrong on this and I can’t be arsed to check because I don’t care
I understand their reasoning to not want to be called containers to avoid confusion in their less-technical target audience (relatively speaking anyway). But as I said above, they use the same features all container systems also use, and for the same reasons.
The difference imho is that Flatpak is a containerization system that is designed with desktop usage in mind, so it has GUI support and hooks for GUI applications, and all the Portals feature to allow temporary access to files/folders/hardware on request.
Docker or LXC are containers for servers and have none of these things
There is this thing called called steam linux runtime, that you can use to launch any application. There are other runtimes as well, and you can make one for yourself afaiaa, that includes any libraries you may wish to include. The Steam linux runtime actually runs most of my older software (games) pretty well (I think it goes back to ubuntu 12.04 for the oldest version).
Valve does maintain Steam Runtime, a binary compatible runtime environment for Steam applications on Linux. Though I am not sure of the license, a general non-Steam specific system could be made and adopted for Linux developers in general.
To clarify, the developer can link against a specific version, but AFAIK there is no way of the OS to have multiple versions of libc, to load on a software by software basis. Why? Because of how libc is architected, which is the main topic of issue in the article.
Now this I did not know! It’s mentioned by JengaFX and also by Valve in their Steam Runtime docs to build against older versions of libc, but I did not understand how that solves anything, if a newer version of libc could break API compatibility. Compat symbols were never mentioned in the article (or I missed it in my multiple readings).
With this in context, it makes sense that you’d just build in a older LTSC environment and be able to distribute to newer systems, beause of these compat symbols. It’s like building on Windows 7 and knowing it would work on 8/10/11.
Steam Play is Valve’s system for running Windows games on Linux and MacOS.
Proton - Compatibility tool for Steam Play based on Wine and additional components (from GitHub)
Steam Runtime - A binary compatible runtime environment for Steam applications on Linux (from GitHub)
Honestly, when I read that article I got the feeling that its main purpose is to spread Fear, Uncertainty, and Doubt around Linux, rather than to promote any real fix.
There is no “Atrocious State of Binary Compatibility” on Linux. Rather, it’s like ack said:
Of course yeah, but Flatpak has other problems (with games/proprietary software specifically) that I mentioned elsewhere already, so just having the runtimes doesn’t change much in this regard.
Maybe it depends on the definition of a container then because the definition is a bit wonky. For me a container is something akin to what Docker/LXC does.
I’m honestly completely and fundamentally opposed to any kind of static compiling or bundling of dependencies with software packages.
All dependencies for every package should always be a part of the systems main package manager and its dependency tree structure. I trust distribution maintainers to manage dependencies with vulnerabilities and back-port fixes where necessary to keep a system secure.
Things like Snapd, AppImage and Flatpak need to go die in a fire. They mask potential dependencies and their vulnerabilities, result in bloat and in general make things worse. I absolutely do not trust each individual fly-by-nigh package maintainer to make sure all of the binary dependencies they have shoved into their Snap/FlatPak/AppImage are properly patched.
We don’t need or want Linux to become more like Windows.
That said,
I think there are some good ideas here, particularly when it comes to major dependency versioning being better tracked and managed in order to make keeping track of compatibility easier.
Ideally though, Linux users should not be installing 3rd party downloaded software like with Windows, so they should not need to be aware of binary compatibility. 100% of the software packages Linux users use, should ideally come straight through the distributions package manager / dependency tree.
Windows users transitioning to Linux need to get it out of their heads that they need to manually find, download and install software like they do with Windows. If it’s not in the distributions repository, just don’t use it.
Then stop running games or proprietary software under Linux. If you want to do that, just use Windows.
Run only the free and open source software that the distribution makes available in its official repositories.
Or… y’know… try to come up with solutions?
Except you are aware things like steam are in distro repos, right? Totally open source of course 
Or maybe just use a free and open source ecosystem for what it is intended. Running free and open source software.
I know, and that is a problem. It shouldn’t be.
Just like how a binary driver with proprietary code taints the kernel, we should be thinking of any binary only distributed software that is not distributed under a free and open source license (preferably Permissive / GPLv2 based) as having no place on, and tainting a Linux installation.
It would be nice if people stopped trying to turn Linux into the next Windows. It will never be that. And if that is what it takes in order for Linux to “succeed” (whatever the hell that means, it has been doing quite nicely for its intended purpose for decades) then it would be better if Linux never succeeds.
Those of us who are dedicated long term Linux users and fans are so precisely because it is not like Windows or MacOS. We don’t need some recent Linux adopters coming over fro Windows in the last 10years trying to tell us how we should be changing the thing we know and love.
If you like how Windows works so much, go back to Windows and leave us alone.
Exactly this.
I have absolutely no sympathy for those trying to pervert Linux into a platform on which to run proprietary commercial for profit junk software as binary blobs. Personally I wish you wouldn’t. Heck, I’d be in favor of erecting barriers to make it as difficult for you as possible.
So please stop doing that.
Absolutely any kind of commercial software or “app store” for paid software is anathema to the very ground upon which the Linux community was built. I’d rather Linux die completely than become yet another Windows. Canonical/Ubuntu deserve to burn in hell for ever trying to launch the Snap Store.
So take your proprietary/commercial/cloud/spyware bullshit and go ruin someone else’s ecosystem with it, will you?
Now here is a funny idea. (Satire actually, but still I kind of like it). How about using some form of cryptographic signing authority to ensure that binaries which are not fully distributed as source code, and free and open source, released under a GPLv2 compatible license simply refuse to run on Linux? 
And I guess “free as in freedom” does not include the freedom to use the system however the hell I like? 