Timothée Besset, a software engineer who works on the Steam client for Valve, took to Mastodon this week to reveal: “Valve is seeing an increasing number of bug reports for issues caused by Canonical’s repackaging of the Steam client through snap”.
“We are not involved with the snap repackaging. It has a lot of issues”, Besset adds, noting that “the best way to install Steam on Debian and derivative operating systems is to […] use the official .deb”.
Those who don’t want to use the official Deb package are instead asked to ‘consider the Flatpak version’ — though like Canonical’s Steam snap the Steam Flatpak is also unofficial, and no directly supported by Valve.
I still don’t understand why everyone was so against static linking before the advent of Snaps/Flatpaks, but are now sooo into them. Windows software devs have been doing this for decades. Link statically and compress with UPX or whatever. This is nothing new, I have no idea why this didn’t become the de-facto standard, but instead things like Snap/Flatpak did. Maybe it was the fact that most people wouldn’t know where to put the binary or not having the icons and desktop files packaged with the app, or maybe that you have to chmod +x the binary in order to run it… also, the lack of a central repo could also be the case (this is the standard nowadays, so people like to have on their desktop what other OSes have as well: PlayStore, iOS Store, Marketplace, etc). I do agree that this does make things easier.
I still don’t understand why everyone was so against static linking before the advent of Snaps/Flatpaks, but are now sooo into them. Windows software devs have been doing this for decades. Link statically and compress with UPX or whatever.
Security is one aspect. You are distributing all the dependencies with your binary now, if a vulnerability is found in any of those dependencies you’re going to have to push out a new build instead of your OS providing you with an updated library.
Memory and storage are the other reasons. Libraries can be shared between running applications, loaded into memory once and stored on disk once. Modern hardware is so powerful now that memory and storage are nothing like the limitations that they once were.
Security is one aspect. You are distributing all the dependencies with your binary now, if a vulnerability is found in any of those dependencies you’re going to have to push out a new build instead of your OS providing you with an updated library.
The same thing is going on now with Snap/Flatpak. They don’t use system libs, they use their own integrated ones. If a lib has a security issue embedded in the app, the app developer has to make a new build. But, even if the developer doesn’t make a new build, that is the only app that is vulnerable, your distro will push a new build in the repos probably a lot sooner than the dev of that app.
As I said, Windows devs have been doing this for ages. Why? DLL hell is one reason, the other is “everything just works out of the box” (no end user late night calls after deployment). This was a security nightmare, I agree, but the alternative was a lot more work (make sure every user out there have those exact dependencies installed which work with your app)… not to mention this scenario: MS pushes a new version of that dll in an update or a redistributable, and guess what, your app doesn’t work with that version 😒. Great, now I gotta debug to see what the reason is. What if the buyer doesn’t want to pay you for this update? It has happened. It’s not my fault that MS pushed this.
We’ve had a situation where specific versions of C++ runtimes had to be installed because the software just doesn’t work with the latest ones. Not to mention hunting down those specific versions is a PITA. And even then there were problems. In the end, a redist repack of every version there is under the sun was the only solution that worked 100%. Mind you, this software works with AD, so it’s not something run locally, this thing uses TCP/IP.
