767
submitted 9 months ago by pnutzh4x0r@lemmy.ndlug.org to c/linux@lemmy.ml

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.

you are viewing a single comment's thread
view the rest of the comments
[-] narc0tic_bird@lemm.ee 114 points 9 months ago

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.

[-] harsh3466@lemmy.world 65 points 9 months ago
[-] joojmachine@lemmy.ml 123 points 9 months ago

obligatory reply to obligatory xkcd

[-] grue@lemmy.world 44 points 9 months ago

Yeah but Snap isn't an improvement.

[-] joojmachine@lemmy.ml 29 points 9 months ago

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

[-] harsh3466@lemmy.world 7 points 9 months ago

Nice. I haven’t seen that one before!

[-] bouh@lemmy.world 4 points 9 months ago

Creating standards to trap users is not improving technology.

[-] LodeMike@lemmy.today 35 points 9 months ago

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

[-] narc0tic_bird@lemm.ee 9 points 9 months ago

Hence I picked the word "format".

load more comments (1 replies)
load more comments (9 replies)
[-] haui_lemmy@lemmy.giftedmc.com 26 points 9 months ago

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.

load more comments (4 replies)
[-] Ephera@lemmy.ml 16 points 9 months ago

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@lemm.ee 6 points 9 months ago

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).

[-] Ephera@lemmy.ml 23 points 9 months ago

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

[-] bjorney@lemmy.ca 8 points 9 months ago

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@lemmy.ml 5 points 9 months ago

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.

load more comments (4 replies)
[-] Vincent@feddit.nl 3 points 9 months ago

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.

load more comments (7 replies)
[-] NekkoDroid@programming.dev 11 points 9 months ago* (last edited 9 months ago)

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.

[-] Lichtblitz@discuss.tchncs.de 7 points 9 months ago* (last edited 9 months ago)

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@lemm.ee 2 points 9 months ago

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.

[-] MonkderZweite@feddit.ch 3 points 9 months ago* (last edited 9 months ago)

and it's probably not great that there are three competing formats for "applications with dependencies included".

Ok in snap/flatpak but i tink that's a bit unfair in appimage. First two are runtimes, second is a file format that does stuff with fuse. That's like saying there should only be one I/O scheduler.

now it's a bit more complicated

Do native for system/environment stuff and simple projects, flatpak for frontend molochs with lots of dependencies, no?

[-] narc0tic_bird@lemm.ee 4 points 9 months ago

I don't think AppImage is a bad technology, but with the comparatively minuscule marketshare Linux desktop has barely any developer/software company can invest the resources to test and maintain packages in all these formats. It's often not worth it for commercial software to offer packages in every possible format (yeah, yeah, open source is great, I know; still, commercial software is real and many people (need to) rely on it).

I've been using Fedora for a couple of weeks (one of my New Year's Resolutions is to completely ditch Windows, so my main computer is now on Fedora :D) and most of the software I use is either available in the official repositories, as an rpm or a Flatpak. But there's the odd piece of software where I can only find AppImage or Snap versions, and often if a Flatpak is available, it's non-official (Steam for example).

So, you potentially have packages from the package manager (mostly deb- or rpm-based, and whatever format Arch uses), then you have AppImage, Snap and Flatpak and some applications are simply an archive with an executable binary. That's a far cry from installing everything from one or two places, which I feel like used for be one of the selling points for Linux (years ago).

Nothing most users can't handle, but it could certainly be more streamlined. Now before I install software, I check the website, then I check whether they offer an official flatpak or an rpm package if it's not in the official Fedora repositories, and if they don't, I check if there's an unofficial one on Flathub, which sometimes has implications. If there's no Flatpak whatsoever, I fall back to standalone binaries/archives when available. It's probably easier to install software on Windows now: download the installer from the official website, install it and done. Most software auto-updates itself.

Having options is great and one of the great things about OSS, but I feel like when it comes to "standards" like these, more collaboration instead of reinventing the wheel over and over again would be better.

load more comments (3 replies)
[-] hangukdise@lemmy.ml 3 points 9 months ago

I thought that valve distributed statically compiled files

[-] dandroid@dandroid.app 2 points 9 months ago

My only complaint about flatpak is that updating them fails like 50% of the time for seemingly no reason, and I just have to run the update command over and over until they are all updated.

[-] PlexSheep@feddit.de 6 points 9 months ago

I've never had an update fail with flatpaks?

[-] dandroid@dandroid.app 2 points 9 months ago

It happens constantly both on my laptop (suse) and my Steam Deck (arch). Same exact behavior. I gave up trying to debug it, and I just keep retrying the update command until the list is empty.

[-] UnsavoryMollusk@lemmy.world 2 points 9 months ago

I am honestly surprised, my arch desktop and my steam deck got no problems of those types. If you find what makes it happens on your systems then maybe it will help improve the tech!

load more comments (1 replies)
load more comments (5 replies)
load more comments (14 replies)
this post was submitted on 18 Jan 2024
767 points (99.1% liked)

Linux

48035 readers
797 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS