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.

octopus_ink, (edited )

I know the “Arch BTW” meme exists for a reason, but one of the reasons I haven’t been able to drag myself away from Arch-based distros in recent years is that it allows me to always have current versions of my software while also just not having to care about all this appimage/flatpak/snap brouhaha.

I guess it’s somewhat of a “pick your poison” kind of situation, but I find dealing with the typical complaints about Arch based distros to be both less of a problem than detractors would have you believe, and less of a headache than having to pick one of three competing alternative packaging approaches, or worse, to use a mix of them all. Standing on the sidelines of the topic it seems like a small number of people really like that these options exist, and I’m happy for those people. But mostly I’m grateful that I don’t have to care about this kind of thing.

Edited to add: Seeing how this thread has developed in the past 5 hours convinces me anew that “on the sidelines” is where I want to stay on this topic. 😁

TimLovesTech,
@TimLovesTech@badatbeing.social avatar

I think if we could drag users (at least gamers) away from these Debian/Ubuntu based distros we could have developers just shipping packages that wouldn’t need to be compatible with some ancient LTS library release, and maybe we wouldn’t need appimage/flatpak/snap at all anymore (or at least only in rare cases).

Telodzrum,

Debian catching strays over Ubuntu’s ubullshit.

alci,

Well, the only thing holding me from switching to Debian is the absence of up to date KDE packages…

Telodzrum,

What about in unstable or testing? I moved to Arch from Debian because I wanted faster releases and it just made sense to move to rolling instead of testing Debian install.

TimLovesTech,
@TimLovesTech@badatbeing.social avatar

I think Debian has a place in the Desktop market, it’s just not gamers or anyone wanting anything new (unless they of course go the flatpak route). Not a perfect analogy, but it’s kinda like gaming on Windows 7 these days because it “just works” for you. Sure you can, but you’re not getting the best of anything that way and all the underlying libraries are outdated and some things just aren’t going to work at all.

Theharpyeagle,

From my perspective as someone who is both getting into gaming on Linux and also not much of a power user, Arch would have to make the installation and maintenance process a lot simpler to attract more people, and I’m not sure that’s something they actually want to do.

Looking at the official Arch installation guide, the average gamer may be overwhelmed by the process here, especially if they’re not comfortable with the terminal. Something like Linux Mint, on the other hand, has a built-in GUI installer with reasonable partitioning defaults, and it comes packaged with stuff like an app manger and update manager, something that will feel much more familiar to someone coming from windows.

TimLovesTech,
@TimLovesTech@badatbeing.social avatar

If you want, or are interested in looking at an easier to manage Arch install I would suggest CachyOS, EndeavorOS, or Garuda Linux.

ScottE, (edited )

100% all this. Canonical has been pushing snaps for awhile, and I wonder if the 12 year LTS for Ubuntu is part of that strategy - want something newer? It’s in the snap store. snap is terrible, worse than flakpak and appimage - but just as you say, as an arch user I don’t have to care. Whatever I want is probably in the AUR if not the main repos. Rolling distros, done right (arch), are an amazing experience.

tigerjerusalem,

As someone who knows nothing about Arch, what do you do if your app exists only as a .deb file? Can you install it?

CalicoJack,

It isn’t recommended, but dpkg will install it if you really want to. You just need to handle dependencies manually.

But it’s a pretty rare issue. If something isn’t available in the official repo, AUR probably has it.

leopold,

I have found no such instances. Software which is only officially packaged as deb will usually be unofficially repackaged on the AUR regardless.

dev_null,

I distribute an app I made for Linux, macOS and Windows. The Linux version I only have available as a .deb. Released recently and has about 200 users so far, but definitely exists. No Arch user contacted me yet.

octopus_ink, (edited )

When folks start wanting it, someone will package it for the AUR, or if it becomes even somewhat mainstream it will end up in the main repos eventually.

dev_null,

Possibly, though I wonder how updates would work then. Currently I have a Debian repository that contains a single package, and installing the .deb from my website also installs the repository so you get updates as with any other package.

If someone repackages it on AUR, I guess they will also need to update it every time I update the .deb, so it’s always behind? Of course it would be better if I provided a first party package for AUR, but I can spend time on that when there is actual interest. Most of my users are on Windows anyway.

octopus_ink, (edited )

Usually what you describe is what they do. Someone “owns” the AUR package (and it’s not quite literally any random user IIRC - you have to be accepted as an AUR maintainer I think) and they then take on the responsibility to repackage it whenever the author (you) releases a new version. There is also a mechanism for users to flag the AUR package as out of date in case that maintainer misses a release, and if they abandon it (or even if folks just don’t like how they package it) someone else can package it, assuming someone else wants to.

Sometimes the AUR maintainer is the dev themselves. I can’t think of a good example currently, but I know I’ve seen it before.

I don’t know the process for how things end up in the official repos, but I would guess it’s similar to however any other distros identify software they want to officially package.

sloppy_diffuser,

They may not have to. For example, Plex on nixos just unpacks the deb and installs the files the “nix” way.

github.com/NixOS/nixpkgs/blob/…/raw.nix

octopus_ink, (edited )

I know you already got another answer, but - it’s very rare that any software for Linux exists that is both 1) not present in the official Arch repos, and also 2) not packaged by a user for the AUR.

Probably 99% of what a typical user (I know we all define that differently) will want doesn’t even require AUR access - it will be in the official Arch repositories and will be up to date to within a few weeks of release.

There are some potentially substantial downsides to the AUR (it’s the Arch USER Repository - so these are not official arch packages) but IME the real world problems are minimal. I would suggest anyone who is new to the Arch way of distributing software should hit up the relevant page on the Arch wiki and make up their own mind before using the AUR - but it’s about being aware of what you are doing more than it is a real warning, if that makes sense. I suspect few Arch or Arch-based users don’t have at least a smidgen of AUR packages on their system. (Edit: That page is very thorough. I think it makes installing from the AUR sound much harder than it needs to be. For most people the command is just “yay -S packagename.” There are gui options that handle all packages including AUR, and yay is not the only cli option, either.)

Interestingly, there are some AUR packages that work by pulling down the deb and deconstructing it for installation on your system - AFAIK it can be that, RPM, a true “compile from source” situation, or I’m guessing some AUR packages are deconstructing snaps\flatpaks\appimages during the install. Whatever the origin of the files, they include a pkgbuild file that tells your system how to either compile or deconstruct and install the software.

dev_null,

I know I ran into this years ago. I think it was some collection manager app for a trading card game that someone had on GitHub and only had .deb releases. Eventually you will want to install something niche.

Grain9325,

Yup, the AUR is a godsend. I barely touch the other methods and only use AppImages when I’m too lazy.

OsrsNeedsF2P,

Appimages when you’re lazy? The fact you have to chmod them is annoying compared to an AUR helper

Grain9325, (edited )

I mean Dolphin gives a prompt for the same thing when I launch it.

BeardedGingerWonder,

I’ve always found the most time consuming thing about arch is having to spend half your life telling everyone you use it.

octopus_ink,

I haven’t used it in years, so hard to remember now.

addie,
@addie@feddit.uk avatar

Nah, it’s repeating the installation process until you finally get enough stuff working to have internet, and then you can bootstrap installing every other bit of software that you need. Thank goodness for rolling release - I can’t imagine having to go through that again.

joe_cool,

You can install Arch directly from a UEFI shell over the Internet: archlinux.org/releng/netboot/
If your BIOS has a UEFI shell that supports DHCP, HTTP and IPv4 PXE you can load the ipxe-arch.efi over HTTP and start installing.

planish,

Does UEFI shell have wget?

HackerJoe,

Depends on the version. All of them (the newer ones with networking) have TFTP. Some even have HTTPS. I think HP Servers even have HTTPS-Boot with client TLS certificates.
None of it works with Wifi though. iPXE has wifi support for some devices but you obviously can’t start it over the Internet. You need to flash a ROM you don’t need or use a USB drive to load it. Then you can boot Linux from the Internet. (That also works if you don’t have a UEFI Shell in BIOS). netboot.xyz can also boot other OSes than Arch.

octopus_ink,

I haven’t done a vanilla arch install for years either, because if that sort of thing is fun for some folks great, but it was only fun once or twice for me. I think a lot of the vanilla arch faithful end up scripting it for fresh installs.

But, FWIW there’s always endeavouros, manjaro, and I’m sure other Arch derivatives I’ve forgotten about. I just did an endeavouros install on new hardware I was given last weekend, and it’s certainly no harder to install than Ubuntu.

maness300, (edited )

That’s the problem with doing everything yourself.

You also have to maintain everything, yourself.

Fuck snaps 🖕

Snapz, (edited )

Yeah. Hey wait? Fuck you!

joyjoy,

🫰Fuck 🫰Snaps 🫰

mariusafa,

I feel the same. My entry distro was ubuntu, and every time I updated major version the whole installation exploded and i had to reinstall it from scratch.

Luckly for me now i use Debian and updating major release is smooth af. Already went through 3 major updates and 0 problems.

Just swap to Debian, Valve. And snap is engineered to waste your time, imo.

DumbAceDragon, (edited )
@DumbAceDragon@sh.itjust.works avatar

It’s canonical that maintains the snap.

Pwnmode,

This is not an issue of what Distro Valve chose to use (SteamOS used Debian now it uses Arch) but is on Canonical for how they package it. I have just been dipping my toes into Linux lately and have been using Manjaro and Nobara and they have been working great for gaming and every day use… Until I play a game like Finals and have to swap to windows.

DrJenkem, (edited )
@DrJenkem@lemmy.blugatch.tube avatar

As far as I know, SteamOS is already based on Debian. The dev is complaining about users trying to install steam on their own Ubuntu installs, not SteamOS.

EDIT: nvm, it used to be Debian, but the newer versions for steamdeck are based on Arch. Apparently they wanted rolling updates so that it would be easier to push out changes more frequently.

ike,

wait, doesn’t steam os use an arch-ish base?

narc0tic_bird,

I don’t even want to hate on Snap, I just think Flatpak is probably superior in almost every way and it’s probably not great that there are three competing formats for “applications with dependencies included”. It was supposed to be “package your app to this format, dear developer, so everyone can use it no matter the distro they use”, now it’s a bit more complicated. Frustrating, as this means developers without that many resources will only offer some formats and whichever you (or your distro) prefers might not be available.

I know that you can get every format to work on every distro (AppImages are just single binaries you can execute), but each has their own first class citizen.

By the way, the unofficial Steam Flatpak has been working well for me under Fedora 39 KDE Spin, but an official one would be great to have.

Lichtblitz, (edited )

Flatpak with Fedora 39 must have come a long way. Almost every tutorial with workarounds or discussion of broken features you can find online is now obsolete. It just works out of the box, especially under KDE. Mostly. That makes searching for actual issues extremely hard because I find myself chasing down paths of issues that have long been resolved.

joyjoy,

Agreed. the only “workarounds” I’ve needed to do (on arch) is install gtk-desktop-portal-{gtk,kde} because it’s not included with kde-plasma5 for some reason.

haui_lemmy,

I didnt want to hate snap either, until I found out its proprietary technology… on a foss OS… since then I‘m pretty over it - and ubuntu for that matter. I‘ll probably switch to debian once ubuntu 23.10 runs out of support.

RuikkaaPrus, (edited )
@RuikkaaPrus@lemmy.ml avatar

Well… Flatpak ships Propietary Software too. And at this point Propietary Software is almost avoidable (unless you have a LibreBoot. I want one too). But it’s reasonable to be frustrated that an operating system as influential as Ubuntu has ended up falling so down in its technology, and that it has the support of a company like Chanonical.

Edit: Thank you for the comments. I didn’t noticed Snap itself is propietary.

arthur,

I think they meant that the Snap itself (or part of it) is proprietary. But I’m not sure.

haui_lemmy,

Not sure if I understand you correctly. Flatpak itself is not proprietary afaik and while people might make flatpaks of proprietary software, the problem with snap is that the snap system itself is proprietary afaik.

So every open source software packaged in snap gets this proprietary stain added to it. Thats what actually bothers me.

TheGrandNagus,

There’s a misunderstanding here. What we mean is that the Snap system itself is proprietary. The server side is proprietary and there’s no way to add repos other than Canonical’s.

Flatpak is open, and anybody can create/add a remote.

Both can be used to package and distribute proprietary software. But the same could be said of .deb or .rpm

NekkoDroid, (edited )
@NekkoDroid@programming.dev avatar

The thing with AppImages is: it requires FUSE2 which doesn’t really get packaged/included by default anymore in a lot of places and the recommendation is “build on the most old and crusty distro you want to support” which just sounds like a nightmare in multiple ways :)

And with snaps the sandboxing only really works on Ubuntu and nowhere else last time I looked into it (then there is also the entire problem if you want to host your own repository/“storefront”).

So really the only universal sandboxing method that effectivly makes sense is Flatpak.

LodeMike,

Snap isn’t a standard actually. It’s closed off.

bjorney,

Every line of snap code that touches your computer is open source, so “closed off” is absolute hyperbole when you are discussing the format

pastermil,

The server is proprietary.

bjorney,

Which is why I phrased my above comment in the very precise and deliberate way I did.

You don’t need to interface with canonical’s server to use snaps, you only need to do so if you want snaps that have been approved by and signed by canonical. Anyone can create a snap and privately distribute and install it, and every part of that process is open source.

grue,

Yeah, but nobody cares about your technical “gotcha.”

bjorney, (edited )

APK isn’t a closed source format just because Google operates the main store.

If there was community effort someone could spin up their own snap store, this person did it forum.snapcraft.io/t/…/27109 - problem is, it would serve no benefit because you would have to create your own signing authority and patch snapd to use those assertions instead - and then you are still relying on a central authority to vet and sign releases and frankly I would rather have my software signed by canonical than someone random guy operating their own snap store

grue, (edited )

Again: nobody cares because practically speaking, the only people using snaps are getting them from Ubuntu, and Ubuntu pushing snaps as the default is the only reason they aren’t using flatpaks intead.

bamboo,

Interestingly though unless it has changed recently, you can’t add a third party snap repository. Canonical’s is hard coded, and when people requested alternate repo support, the issue was closed with a response that users seeking third party repos could just edit the string and recompile. Not the most useful solution

zephr_c,

Canonical specifically went out of their way to create a closed ecosystem with snaps, and you think that’s not “closed off” because they only allow you to download the open source parts of the snap software?

narc0tic_bird,

Hence I picked the word “format”.

harsh3466,

Obligatory xkcd

https://lemmy.world/pictrs/image/0ea3317a-569e-41dd-b2df-209721b6b20e.png

joojmachine,

obligatory reply to obligatory xkcd

https://lemmy.ml/pictrs/image/2c3a02be-64cf-4ace-aabc-60c0ca9c7324.png

bouh,

Creating standards to trap users is not improving technology.

harsh3466,

Nice. I haven’t seen that one before!

grue,

Yeah but Snap isn’t an improvement.

joojmachine,

I know, I’m on the Flatpak side, just appreciate the intention behind snaps (although I quite frankly hate the execution).

hangukdise,

I thought that valve distributed statically compiled files

Ephera,

Personally, I don’t get why devs would elect to package for Snap, in favor of Flatpak or AppImage. I guess, if your toolchain offers Snap packaging out of the box, then might as well. But aside from that, do you not just reach fewer users…?

narc0tic_bird,

Yes and no. Last time I checked, Ubuntu was the most used desktop Linux OS, and it obviously uses Snap (and has Flatpak disabled by default).

iopq,

How do you figure? For example, Arch Linux community on r*ddit is bigger than the Ubuntu one

Where did you get the numbers?

Ephera,

If you’re on Ubuntu, you can just ask your question in the normal Linux community or in a search engine. You don’t need to go to a special Ubuntu community.

That’s at least, how it makes sense to me. In general, I’ve seen many niche distros have very active communities, because everyone just ruts together and helps each other out.

…which is to say, I don’t think there are accurate marketshare statistics, because no telemetry, but my impression is also that Ubuntu is still popular out in the wild.

narc0tic_bird,

Hard to find raw numbers backed by good sources.

If you filter the Steam Hardware Survey for December 2023 by Linux, you can see Arch has a market share of 7.85% (excluding SteamOS on the Deck, which is technically based on Arch and has 40.53%) while Ubuntu 22.04.3 LTS - a specific Ubuntu version - already has 7.04% on its own.

But that’s also just Steam users. Ubuntu is one of the few Linux distributions that OEMs ship preinstalled and officially support on some of their devices (Dell for example). Another example is Fedora iirc, which Lenovo ships or at least used to ship as an option on some of their ThinkPad notebooks.

I’d assume the Arch community on Reddit is bigger than the Ubuntu community as it’s geared towards tech-savvy people. Going by Reddit community size wouldn’t make much sense though. Even if you add up the member count of the r/windows, r/windows10 and r/windows11 community (which doesn’t make a lot of sense as most users are probably not unique), it’s only like 3-4x the members of r/archlinux, which doesn’t translate to market share whatsoever.

I don’t really have hard numbers, sorry. Should’ve checked first. I guess I just assumed because of the OEM support and being relatively easy to install and maintain for the average guy (in comparison) that it was the leading Linux desktop distro in terms of marketshare. I’m still assuming this is the case for the reasons stated, but can’t tell you with 100% certainty.

grue,

I don’t really have hard numbers, sorry.

It’s impossible to measure since sharing copyleft stuff can’t be tracked like sales of proprietary software can. There’s no need to apologize about not doing the impossible.

iopq,

Well, most of windows users don’t even know they are using it, they think they are using a “PC” as opposed to Mac

Any Linux desktop user is already very tech savvy, I doubt there are any Ubuntu users that don’t know they are using Ubuntu so the windows commission is not apt

TheGrandNagus,

So? The AMD subreddit is larger than either Nvidia’s or Intel’s (in the case of Intel, by a lot). Both of them have a greater market share than AMD in their respective markets.

Porsche has over double the subs of Toyota, yet Toyota sells 33x the amount of cars.

Subs means zero.

iopq,

Again, my mom is not on the Intel subreddit because she doesn’t know she has an Intel processor. In fact, she used to work for Intel, and she still doesn’t care

Ubuntu is nowhere near popular enough to be a default. I’m just wondering how to count the market share accurately

Ephera,

Ah, I hadn’t realized Canonical was so awful as to disable the format everyone else agreed on, but seems you’re right: www.omgubuntu.co.uk/…/ubuntu-flavors-no-flatpak

Vincent,

Ubuntu itself never natively came with Flatpak though. Some flavours might have, but their marketshare is also a lot smaller.

Of course, if Ubuntu ever decided to ship with Flatpak natively, that would instantly become the obvious choice.

bjorney,

They didn’t “disable the format”

From your own link:

Do keep in mind that “not installed by default” is not the same as “not available to install at all”. To this end, Flatpak continues to be available in the Ubuntu repos, and users of Ubuntu flavors are free to install Flatpak

Ephera,

Well, yeah, you can enable it. But if it’s not active in their GUI software store by default, then many users will not find / look for it. It’s rather important for a package format that you don’t have to separately install it.

bjorney,

Why do you need to have two package formats that do the same thing installed by default? If you could install snaps and flatpaks both from the same store you could have 2 (or 3 if you also installed the .deb) copies of the same app, like steam etc installed, and user sessions and games set up on one wouldn’t be launchable from the other because they all store their state and config in different locations - the only way to know what config your program is launching with would be to inspect and rename the launcher scripts. If you are intending to support naive users this is the absolute worst case scenario. It would be like debian including pacman by default as well alongside apt for maximum user accessibility confusion.

Ephera,

Because many apps will (or would prefer to) only be bundled as Flatpak. I agree that the deduplication is not a trivial problem to solve, even if they might have already solved it for DEBs (I don’t know).

But your entire comment could just as well be a rant why Canonical shouldn’t have introduced Snaps in the first place. It might be good for their bank account, if they can somehow monetize part of the cake, but splitting the cake even further, after it’s already split into DEB, RPM, AppImage, Flatpak, Docker, APK etc., that’s maximum user confusion.

bjorney, (edited )

Because many apps will (or would prefer to) only be bundled as Flatpak.

This reads like speculation to me and is directly contrary to the file counts on flathub and snapcraft. What about CLI apps and server software? How are they supposed to distribute their software if not via snap? (Flatpak doesn’t support this well)

could just as well be a rant why Canonical shouldn’t have introduced Snaps in the first place

You are acting like Ubuntu core (and snaps) came after flatpak? Snaps were announced almost a decade ago

Like, I get you don’t like snaps, but your argument is basically “every Linux distribution should ship the same default software, and it should be the software I choose”

Ephera,

I don’t know why you’re trying to interpret all kinds of things into my comment. I did not say any of that. This isn’t some competition to show who’s technically more correct.

morriscox,

Welcome to Linux.

narc0tic_bird,

Thanks buddy

TimLovesTech,
@TimLovesTech@badatbeing.social avatar

I’m sure Canonical’s neverending death march towards Snap, along with the OS running outdated packages, is why Valve no longer uses Ubuntu for SteamOS development. The greatest April Fools was Ubuntu dropping Snaps because so many people were saying how they could go back to using Ubuntu again…then they noticed it was a joke and the sadness set in.

QuaternionsRock,

Why do people hate snap over flatpak? I feel like I’ve read a thread or two about it, but I haven’t seen an answer that was particularly satisfying (almost definitely for a lack of trying on my part, to be clear).

zyratoxx, (edited )
@zyratoxx@lemm.ee avatar
  • Flatpak is open source, Snap isn’t
  • Flatpak allows other repositories besides the official one, therefore having the ability to be decentralised, Snap doesn’t
  • Canonical (the company behind Snap and Ubuntu) is hated for some past decisions they made with Ubuntu
  • and more

(The only thing I really prefer Snap over Flatpak is that you need the whole package name in Flatpak (like com.valvesoftware.Steam for Steam) whilst you can simply use “steam” in snap but that’s due to decentralisation vs centralisation I guess and overall a minor problem for me)

TheGrandNagus, (edited )
  • Proprietary on the server/distribution end
  • Controlled 100% by Canonical
  • Worse performance, particularly in terms of app startup times
  • Snaps are mounted as separate filesystems, so it can make things look cluttered in your file explorer or when you’re listing stuff with lsblk
  • Canonical often forces users to use Snaps even when users have explicitly tried to install with apt. e.g. you run sudo apt install firefox and it installs a Snap
  • It hasn’t gained traction with other distros like Flatpak has, and Canonical’s insistence on backing the “wrong” standard means Linux will continue to be more fragmented than it would be if they also went along with what has become the de facto standard

There are however benefits of snaps. It works for better for terminal programs, and Canonical can even package system stuff like the kernel as a snap - as you can imagine, this might be a very powerful tool when it comes to an immutable version of Ubuntu.

QuaternionsRock,

Proprietary on the server/distribution end

Zoinks!

umbrella, (edited )
@umbrella@lemmy.ml avatar

Snap startup times are awful, tens of seconds to open a simple text editor, even on an nvme ssd…

edit: Also it doesnt bother following XDG specifications, further cluttering our home folders.

Thwompthwomp,

Snaps just act strange. They update in weird ways, it’s always automatic and it’s confusing how to keep something in a version that won’t auto update. It’s been a bad experience for me.

Hominine,
@Hominine@lemmy.world avatar

I was certain you had to be joking in this post, holy shit.

  • 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 31