Canonical's Steam Snap is Causing Headaches for Valve

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.

mlg,
@mlg@lemmy.world avatar

I’m really hoping this all forces Ubuntu out as the face of desktop Linux.

It’s been pretty low tier for years now, and Canonical just proves corporate backing doesn’t guarantee a good distro.

Snap is pretty garbage, default GNOME is horrendous, the repos break every other month, apt is still pretty lame despite being an user upgrade for apt-get, the packages are neither stable nor cutting edge, they change core OS backends like every update which breaks configs and makes documentation obsolete.

I’d like to suggest Fedora as the new goto, but I feel like it’s a bit too privacy and FOSS oriented which may scare away new users.

Debian is great but it doesn’t have latest packages which isn’t optimal as performance upgrades would take time to release or need to be manually installed.

phr0g,

Well, I’d prefer Canonical to fix their shit, instead of forcing immature products onto users. I’m not against snap per se, as there are valid reasons for sandboxing, especially for games (remember when Steam accidentally wiped some user’s home folders back in 2015? Sandboxing would have prevented that).

However, in its current state, snap causes just too much friction. For example Firefox can’t remember the last used directory for up/downloads, Steam snap will just create a new data directory (forgetting about the games already downloaded), there’s no way to allow additional folders (like /net from autofs) in snap apps etc. It’s just a myriad of issues which make working with the system unnecessarily complex and frustrating, and there seems to be little progress fixing those.

LeroyJenkins,

unfortunately, industry loves shit like Ubuntu and RHEL because of their corporate backing. comps love having the insurance of someone to blame or somebody to fix their shit when things hit the fan. I’ve worked for many comps who choose RHEL for that alone. Should we choose the OS built by a bunch of randos in their basement, or something backed by Red Hat where I can just pay them money to handle my support tickets faster if shit blows up? or who tf do I have my cyber liabilities insurance guys sue if the OS has a huge fuckin problem? I want a company behind that shit.

Zetta,

Fedora is the best!

(In my opinion)

thecookingsenpai,
@thecookingsenpai@lemmy.world avatar

Tbh i never found an app that runs better on snap than on deb

Same goes for almost anything like snap

boaratio,

Good. Snap is an abomination.

merthyr1831,

This is a big issue with Snap. It may be like Flatpak, allowing devs to set their own dependencies for ALL distros, but its poor uptake outside of Ubuntu’s ecosystem means that it’s no different to yet another distro repackaging system.

Flatpak, or even Nixpkgs, are the future because they allow devs to have control over the distribution of their software. Snap being such a closed ecosystem in comparison only means it will replicate many of the problems we’ve found with traditional (re)packaging systems.

mac,
@mac@infosec.pub avatar

I can’t speak for Flatpak as I haven’t tried it but nixpkgs are beautiful to work with and configuration of my system has become completely reproducible in a clean format.

merthyr1831,

As a dev, you can just distribute a nixpkg with whatever build tool inside. That beats the current system of “native” packages where your software is repacked and then maintained by half a dozen teams for different distros that use different dependencies and update cadences.

Bottles has gone as far as to demand its fedora package be removed and now shows a warning if you’re not using the flatpak version because repackers just don’t properly test all their software (how can they? there are thousands of apps in these repos!)

mac,
@mac@infosec.pub avatar

Yeah there are some issues with compatibility, I’ve found a couple of apps that error on my Mac.

How does it compare to Flatpak?

merthyr1831,

nix is a “native” packaging format. Apps are compiled for your host OS and run in that environment with no restrictions, for better or worse.

Flatpaks are containers. They provide a virtual OS to the application such as the file system, and accessing host OS features is done through “portals” which just means you can give/revoke the ability of the app to access your host OS resources such as networking, file access etc.

Flatpaks are therefore much safer in theory. But Nix packages are lower overhead, and can interact like any built-in software binary that you’d have when you spin up a fresh install of, say, debian.

Nix packages are harder to use IMO thanks to their poor documentation and lack of GUI package manager support (not that it’s impossible, just that it’s been a niche system for most of its life) and since most people are accustomed to flatpaks and their permissions system (and the fact it comes preinstalled on most distros) so flatpak is still pretty ubiquitous, even for NIxOS users

danielfgom, (edited )
@danielfgom@lemmy.world avatar

The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.

This would ensure security, as well as a proper functioning flatpak/snap and also all feedback would be directed to the Dev.

I’ve never liked the fact that Canonical and whoever can make Snaps and Flatpaks of other people’s software. There is zero security guarantee, zero guarantee they’ll update it and zero guarantee it will work.

Just because Snap and Flatpak exist doesn’t mean just anyone should be able to just make them.

If Valve only chooses to make a deb then so be it! It’s their product!

anothermember,

The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.

Says who? If it were the case, Linux would either be a nightmare of fragmentation or become centralised on one distribution. Distros need to be able to package their own software, and these are kind of like distributions. Also since we’re talking about proprietary software here, is it really any better security practice if the “real dev” packages it or somebody else, they both could contain malicious code.

danielfgom,
@danielfgom@lemmy.world avatar

Valve are not going to put malicious code on their app. Neither is VLC or any other FOSS developer.

The distros should stick to packaging their repo apps and leave the Snap/FlatPak tech as an alternative to the original dev if they decide they want to use that.

We can’t have Bob from nowhere packaging Valve, then not updating it or patching it because he doesn’t have time. Or 5 Bob’s all doing the same thing with 5 copies of Valve on the Store.

It’s crazy. This is what causes fragmentation. Flathub should vet every app and if you are not the dev of the app, you may not host it on Flathub. You’re still welcome to make a Flatpak for home use on your own pc but not for wide distribution.

jyte,

isn’t that kind of what AUR is, and exactly what people love about arch ?

danielfgom,
@danielfgom@lemmy.world avatar

Yes but if you use an Arch distro like Endeavour, they won’t support you with issues caused by AUR apps. Because of these reasons I mentioned.

anothermember,

Valve are not going to put malicious code on their app. Neither is VLC or any other FOSS developer.

How would you know that? It’s not like it’s something that doesn’t happen.

Or 5 Bob’s all doing the same thing with 5 copies of Valve on the Store.

It’s crazy. This is what causes fragmentation.

I don’t know what snaps are like but that’s clearly a non-existent problem on Flathub.

Flathub should vet every app and if you are not the dev of the app, you may not host it on Flathub. You’re still welcome to make a Flatpak for home use on your own pc but not for wide distribution.

I don’t know why you feel like there’s permission involved. You don’t have to use Flathub, therefore Flathub can have what ever policies it likes. Users can set up a different flatpak repo if there’s a need.

danielfgom,
@danielfgom@lemmy.world avatar

That’s not my point. I use Flathub but I try to only use verified apps which were packaged by the actual dev.

I’d rather get a deb from the official dev than a flatpak from flathub packaged by someone who is essentially anonymous and could easily inject malicious code.

If you think the dev himself could inject malicious code in the official app, then you should be super aware that an anonymous Joe can too, and is far more likely to.

Anyway flatpak ideally was supposed to save Devs the work of packaging for every distro so it makes sense that the real actual verified dev of the app would package the flatpak/snap himself

NotJustForMe,

How is “the dev of the app” defined, exaxtly?

danielfgom,
@danielfgom@lemmy.world avatar

The official Developer of the app. E.g. the official dev of Blender is blender.org. The flatpak people give them a line of code to embed in their website and they use that to verify that the dev really is blender.org and not a malicious actor.

OsrsNeedsF2P,

Wait until you find out how distro packaging works

Yearly1845,

deleted_by_author

    •
    danielfgom,
    @danielfgom@lemmy.world avatar

    How so? How does ensuring they only the real dev of the app is also the only one allowed to package it hurt desktop adoption.

    It’s very easy to enforce. Flathub need to verify the identity of the person submitting the Flatpak to make sure it’s the app’s dev uploading it and not Joe Smith or nsa.gov…

    HawlSera,

    Okay…

    What’s a Steam Snap? I don’t know what that is

    Reil,

    Snaps are a relatively recent way of packaging application installations in certain flavors of Linux. Steam is Valve’s game distribution platform (amongst other things).

    There’s an unofficial Snap package to install Steam and it apparently doesn’t work so good

    Falcon,

    Snap is a sandboxed environment to install applications in.

    Flatpak is a more portable implementation of the same broad idea, it downloads a chroot and runs applications from within using a separate program called bubblewrap (one could, in theory, use chroot to run apps from within the downloaded flatpak images, bubblewrap offers further isolation through things like namespaces and cgroups etc. )

    Snap, unlike flatpak, is a Canonical specific implementation that has a reputation for breaking a lot of things.

    barsoap, (edited )

    It’s perfectly possible to isolate a steam install, NixOS does that by default to even get it running (on NixOS nothing is where any binary blob expects it to be). There was a very brief issue with experimental steam when they tightened up their own sandboxing and doing sandbox-in-sandbox broke stuff but that was fixed before release as Valve is, indeed, responsive, even if the distribution isn’t officially supported. But you gotta have some professionalism and have institutional continuity, they don’t want to deal with J. Random Hacker doing a one-off packaging job. Or distros trying to be smart and replace the steam runtime with their own library versions. Basically, assume that the whole thing runs directly on the kernel, make sure to have graphics drivers, and you’ll be fine running it as-is.

    captain_aggravated,
    @captain_aggravated@sh.itjust.works avatar

    Snap is Canonical’s (developers of Ubuntu) attempt at their own containerized software package format, conceptually similar to Flatpak in some ways but differing in details of implementation. One major note is the back end is kept closed source so you cannot host your own Snap repo, which ruffles some feathers.

    Apparently distributing Steam (Valve’s video game store/launcher) in Snap format is causing some problems.

    randomaside,
    @randomaside@lemmy.dbzer0.com avatar

    Ubuntu used to get a lot of undeserved hate but lately the hate feels deserved. Ubuntu has been the face of the usable desktop Linux for a long time and they just keep tripping over themselves every time they try to move forward.

    Their intentions are usually good. A lot of things they propose usually end up being adopted by the community at large (just not their implementation). They seem to just yank everyone’s chain a little too hard in the direction we’re eventually going to go and we all resent them for that.

    Off the top of my head, there was Upstart (init system), there was unity (desktop), and now snaps (containerized packaging). All of these were good ideas but implemented poorly and with a general lack of support from the community. In almost each case in the past what’s happened is that once they run out of developers who champion the tech, they eventually get onboard with whatever Debian and Rhel are doing once they were caught up and settled.

    Valve’s lack of interest in maintaining the snap makes sense. The development on the Ubuntu platform is very opinionated in a way where the developers of the software (valve) really want nothing to do with Canonicals snaps.

    On another note: my favorite thing about the Ubuntu server was LXD + ZFS integration. Both have been snapified. It was incredibly useful and stable. Stephane Graber has forked the project now into INCUS. It looks very promising.

    Falcon,

    The ZFS stuff was exciting! Are they still incorporating zfs in current releases though?

    randomaside,
    @randomaside@lemmy.dbzer0.com avatar

    I think they are! I’m still trying to do more with ZFS everyday.

    OsrsNeedsF2P,

    LXD got better with the AGPL license, so Canonical did the right thing there.

    (I know they added a CLA but it’s still way better than the permissive license they had before)

    ulu_mulu, (edited )

    This might be an unpopular opinion but I really don’t get this trend of wanting to containerized just about everything, it feels like a FOTM rather than doing something that makes sense.

    I mean, containers are fantastic tools and can help solve compatibility problems and make things more secure, especially on servers, but putting everything into containers on the desktop doesn’t make any sense to me.

    One of the big advantages Linux always had over Windows is shared components, so packages are much smaller and updating the whole system is way faster, if every single application comes with its own stuff (like it does on Windows) you lose that advantage.

    Ubuntu’s obsession with snaps is one of the reasons I stopped using it years ago, I don’t want containers forced upon me, I want to be free to decide if/when to use them (I prefer flatpack and appimage).

    Debian derivatives that don’t “reinvent the wheel” is the way to go for me, I’ve been using Linux MX on my gaming desktop and LMDE on laptop for years and I couldn’t be happier, no problem whatsoever with Steam either.

    AnyOldName3,
    @AnyOldName3@lemmy.world avatar

    Shared components work brilliantly in a fantasy world where nothing uses new features of a library or depends on bug fixes in new versions of a library, and no library ever has releases with regressions or updates that change the API. That’s not the case, though, so often there’ll exist no single version of a dependency that makes all the software on your machine actually compile and be minimally buggy. If you’re lucky, downstream packagers will make different packages for different versions of things they know cause this kind of problem so they can be installed side by side, or maintain a collection of patches to create a version that makes everything work even though no actual release would, but sometimes they do things like remove version range checks from CMake so things build, but don’t even end up running.

    NotJustForMe,

    Shared containers work beautifully for a lot of things, though, many programs aren’t all that sensitive either. Making snaps for the tricky ones makes sense. Having snaps for all of them is ridiculous.

    I can count the software requiring repo-pins on one hand on my desktop. For those, snaps make sense, replacing the need for any pins. Snaps are less confusing than pins. IMO.

    It reminds me of Python programming, with requirements pinned to version ranges. Some dev-teams forget, and their apps won’t work out of the box. Sometimes, software still works ten years later, if they only use the most common arguments and commands from the packages.

    Snaps <==> Virtualenv.

    randomaside,
    @randomaside@lemmy.dbzer0.com avatar

    I agree with a lot of your points but I do think containers a great solution.

    I’ve been a really big fan of Universal Blue lately. It presents a strong argument for containerizing everything. Your core is immutable and atomic which makes upgrades seamless. User land lives in a container and just gets layered back on top afterwards.

    phoenixz,

    Wasn’t there MIR as well?

    randomaside,
    @randomaside@lemmy.dbzer0.com avatar

    Yeah, I think as the replacement for x before Wayland?

    flux,

    I do think the idea behind snap isn’t all about pushing the Linux platform as such forward, but to specifically gain a market advantage to Ubuntu.

    Why else is finding documentation for changing the default store so difficult? And I don’t think you can even have multiple “repositories” there–quite unlike all other Linux packaging systems out there. (Corrections welcome!)

    UnaSolaEstrellaLibre,

    Kinda saw this coming sooner or later.

    I remember asking in one of their articles if they had planned to reign over (or partner up) the project over to Valve once it was ready and said they had no plans.

    moon,

    Would be cool if they just straight up supported flatpaks. That’s been my main way of gaming for a couple years now, and it works great. The downside is that the folder structure is confusing so it makes things like modding pretty difficult.

    superbirra,

    or, you know, you can use your distro packages

    moon,

    or, you know, you could use a much better and consistent platform

    Falcon,

    Well, no, neither approach is better than the other, it’s apples and oranges.

    There will always be a place for installing native applications. In the least analysis, the container itself should probably have some dependencies packaged for the target program.

    The benefits of containerisation are obvious, but it’s been a lot of work and there are still edge cases to iron out.

    FreeBSD has had jails since 2000. Linux, however, only got namespaces in 2008 and the first bubblewrap release on GitHub was 2016.

    I’ve been using chroots and containers for development for about 2 years now and it’s been fantastic, however, I’m still grateful I don’t have to jump inside one every time I need to write a python script.

    barsoap,

    I’m still grateful I don’t have to jump inside one every time I need to write a python script.

    Honestly, I’m on NixOS and it’s not a bother because it saves time down the line when your script would break during a system upgrade which it doesn’t on NixOS as without you telling it to, it will still use all the old dependencies. Also you already have a couple of flake.nix floating around you can just copy and adjust and direnv does the rest.

    superbirra,

    I use debian, I’m happy and definitely have no idea what you are talking about :)

    TheGrandNagus, (edited )

    Debian is one of the distros where flatpaks are most appropriate lol, it’s the best way to not have programs that are really old

    Adding weird third party repositories that can cause all kinds of issues probably isn’t the best idea

    superbirra,

    tbf, flatpaks are problematic shit noobs tend to appreciate because reasons. That said, beside the fact steam ships its own chroot, I’m a happy sid user and I don’t even have this imaginary problem of things being ‘very old’ sooo … but I can confirm you shouldn’t add weird third party repos or shitty flatpaks :)

    TheGrandNagus, (edited )

    It’s not just noobs that appreciate flatpak. Flatpak is good all-round.

    And the problem of Debian packages being old is very much not imaginary lol. Debian has only just moved beyond Gnome 3.38/Plasma 5.20/kernel version 5.10.

    That’s ancient. And that’s not to mention the other software repos, which are often updated at an even slower pace.

    Don’t assume that just because you want extremely outdated packages, everyone else must want the same.

    superbirra, (edited )

    you normally skip reading half of the comments you reply to, eh? :) ciao ciao from my debian system which does everything, including paying my rent and a bit more, w/o this shit ;)

    TheGrandNagus,

    I didn’t ignore anything.

    And you don’t need to be so defensive. Nobody said Debian is bad or that you can’t use it to make money, just that it being severely outdated can be an issue, and it can. Flatpak helps, but it doesn’t completely fix it.

    My comment wasn’t meant to hurt your feelings.

    superbirra,

    lol I’m not defensive at all hahahaha rest assured my opinions aren’t changed by such a stupid zealot conversation, also this fact you don’t entirely read comments you’re replying about contibute to the lulz. Don’t react too bad to the money thing, one day or another you could also start working in this industry but if I could choose I’d go w/ dog training (I’m speaking for me, I’d really go that way). Cheers my friend

    TheGrandNagus, (edited )

    I dunno, it sounds awfully defensive to me. It wasn’t meant to hurt you, it’s just a discussion about software packaging. There’s no personal attacks here.

    I did read your comments, and despite trying to change the topic, create strawmen, and shout ad-hominems, it doesn’t change the fact that it’s reasonable to say Debian packages are often very, very old and outdated. Because they are.

    That may not be an issue for you, but it is for many.

    You shouldn’t let that make you upset, it doesn’t invalidate your use-case.

    superbirra,

    hahaha I swear to you that seeing you strain so hard to push your fallacies who knows where makes me laugh. Believe it or not, there remains a world of people out there laughing at those who use this garbage, and your social media woes will not, as usual, shift half an ounce of reality :) believe it or not, lemmy is not reality, outside those servers there is a real world :) but please, feel welcomed to keep supporting I don’t know what theory, you’re welcome, at least at this party :PP

    TheGrandNagus,

    Now you’re just talking absolute gobbledegook.

    superbirra,

    I don’t know man, the important thing is that you stay calm while I continue to mind my own business. Say hello to the computer vegans from me, and ofc stay hydrated :P and please, PLEASE, do not mumble 3h again your next response sweetie <3

    stinerman,
    @stinerman@midwest.social avatar

    I don’t mind the old packages (I’m typing from Debian Stable right now). If that’s a bother for other people Debian Stable isn’t the way to go. Even I wouldn’t recommend Stable on a desktop/laptop unless that person knew what they were getting themselves into. I used to run Sid a while back, but didn’t want to have to deal with the mild breakage from time to time. Generally speaking it’s “stable enough” for most people, especially on a daily driver.

    That being said, I have a few flatpaks running, but that’s mostly because they’re apps that aren’t packaged for Debian.

    TheGrandNagus, (edited )

    Yeah. And if it works for you, it’s good. I have a headless Debian home server running in my house right now.

    I’m just saying it’s completely valid to not be into Debian because the packages are ancient, just as it’s also completely valid to not be into Arch because the packages are too bleeding edge.

    stinerman,
    @stinerman@midwest.social avatar

    Agreed, but I think there are enough flavors of Debian to satisfy someone if they want newer packages without resorting to Flatpak/Snap/etc.

    TheGrandNagus,

    You say “resorting” like using flatpak is awful

    moon,

    It’s actually a massive issue on Debian

    superbirra,

    mmh, what? :)

    moon,

    ?

    superbirra,

    👍🏾

    OsrsNeedsF2P,

    Steam’s runtime is already sandbox-ception. Flatpak might be more appealing to Valve than it seems.

    superbirra,

    I see no value in switching from current situation (in-repo deb pkg + steam autoupdates) to flat/snap/farts, which I don’t use at all…

    OsrsNeedsF2P,

    It’s not about you, it’s about what’s easier for Valve. If Valve is fine packaging, and getting bug reports, from all the different distributions, they’ll keep doing things as is. But as a Linux app developer myself, I exclusively publish to Flatpak because it guarantees everyone has the same system.

    superbirra,

    you’re at best uninformed about how the process actually works and what’s the role of a distro maintainer, a distro project, upstream authors. Not that every piece of software has enough value to be included in this process so maybe it will make sense to package your stuff by yourself.

    mp3,
    @mp3@lemmy.ca avatar

    Maybe they’ll get there eventually, considering this is their method of choice for installing 3rd party apps on SteamOS 3.0.

    Dehydrated, (edited )

    Let me simplify that: Canonical’s Steam Snap is Causing Headaches for Valve

    Solrac,

    The one Linux Distro that people will look for out of popularity, fucking up the of the Linux user base? Of course, thanks canonical.

    OsrsNeedsF2P,

    Snaps were designed to solve dependency hell, get modern software, security, among other issues. If it weren’t for the fact Flatpak does a better job, many more people would be praising Snap.

    It’s good that Canonical is trying to make the desktop better. It would be better if they focused their efforts elsewhere.

    friend_of_satan, (edited )

    I run all headless Linux machines, and snapd always managed to show up somehow. It’s got shared lib dependencies so that shit like Firefox would be installed and have snap mount points on my machine. Just a bunch of useless noisy garbage on a headless machine. I finally solved the problem by switching to Debian.

    I don’t care what flatpak does or does not do, IMHO snap sucks objectively.

    captain_aggravated,
    @captain_aggravated@sh.itjust.works avatar

    Flatpak is intended for end-user graphical applications, not many terminal applications are packaged by Flatpak so it makes sense why it wouldn’t show up. Snap IIRC was first intended for their embedded system.

    NaNABCV,
    @NaNABCV@lemmy.world avatar

    A good reason to dual boot

    Gingernate,

    Or use flatpak or .deb

    woelkchen,
    @woelkchen@lemmy.world avatar

    Why dual boot with Fedora when you can just use it exclusively?

    Gingernate,

    You spelled openSuse wrong.

    I use fedora BTW lol

    woelkchen, (edited )
    @woelkchen@lemmy.world avatar

    You spelled openSuse wrong.

    openSUSE

    FTFY

    OsrsNeedsF2P,

    “snaps are slow and buggy! I’m gonna use Windowzzz!!”

    Neon,

    Don’t they own the Code?

    Can’t they just cease-and-desist them if they cause them trouble?

    swag_money,

    guys hear me out. steam os: debian edition

    shasta,

    This is not a problem with steam OS though

    cupcakezealot,
    @cupcakezealot@lemmy.blahaj.zone avatar

    Canonical’s Steam Snap is Causing Headaches for Valve

    Natanael,

    Thanos snapped the uptime

    OscarRobin,
    1. Ubuntu wants to own snap, with their own proprietary store etc which runs against alternatives like Flatpak and goes against the FOS ethos
    2. Snap is slower and worse than Flatpak (the most popular alternative) in most ways, with very few pros that will likely be caught-up-to soon too
  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • linux@lemmy.ml
  • localhost
  • All magazines
    •
    Loading…
    Loading the web debug toolbar…
    Attempt #

    Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16781312 bytes) in /var/www/kbin/kbin/vendor/symfony/http-kernel/Profiler/FileProfilerStorage.php on line 171

    Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 10502144 bytes) in /var/www/kbin/kbin/vendor/symfony/error-handler/Resources/views/logs.html.php on line 38