- cross-posted to:
- linux@lemmy.world
- cross-posted to:
- linux@lemmy.world
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 must log in or register to comment.
Who the fuck was asking for a Steam Snap.
JFC
Give up on snaps. It’s not gonna happen. Whatever benefits they claim they could provide could be merged into Flatpak and everyone wins.
It’s Canonical. They’ll perfect snaps in 8 years, then give it up
Snap is what finally got me to drop Ubuntu for Debian. Such a pain.
Already gave up. Switched to Debian and it’s been great. I loved Ubuntu, but fuck snap all the bullshit that comes with it.
Flatpak is not designed to solve all the same problems as snap they have very different scopes and goals. It’s really only Linux hobbyists that see these as comparable technologies.
Also the Steam flatpak is unofficial just like the snap, they would be unwilling to support flatpak issues as well.
Linux hobbyists
Who else has opinions on snaps vs. flatpacks? Are they distinct to the “Linux professional” somehow?
Yes? How is this a question?
Counterpoint: Snaps work fine for me, really convenient. But flatpak always shits the bed on my internet, it also needs huge Nvidia driver packages of it’s own if you have an Nvidia GPU (my laptop has one)
Snap on the other hand is very much fire and forget
Canonical’s SteamSnap is Causing Headachesfor Valve-
Ubuntu wants to own snap, with their own proprietary store etc which runs against alternatives like Flatpak and goes against the FOS ethos
-
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
-
Thanos snapped the uptime
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.
I was certain you had to be joking in this post, holy shit.
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).
-
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.
Proprietary on the server/distribution end
Zoinks!
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.
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.
-
- 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)
That’s gotta be the funniest backfire for an April Fools’ joke I’ve seen in a while lmao
And still is, as Google still has it on the first page of results for “Ubuntu without snaps”.
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.
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.
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!)
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?
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
Let me simplify that:
Canonical’s SteamSnap is Causing Headachesfor ValveUbuntu 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.
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.
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.
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.
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.
Wasn’t there MIR as well?
Yeah, I think as the replacement for x before Wayland?
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!)
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)
The ZFS stuff was exciting! Are they still incorporating zfs in current releases though?
I think they are! I’m still trying to do more with ZFS everyday.
The article says that steam showing a notice on snap installs that it isn’t an official package and to report errors to snap would be extreme. But that seems pretty reasonable to me, especially since the small package doesn’t include that in its own description. Is there any reason why that would be considered extreme, in the face of higher than normal error rates with the package, and lack of appropriate package description?
It’s not extreme. This is an opinion piece posted on OMGUbuntu, so I’ll let you figure out where their biases lie.
Honestly, that seems like the nicest way to solve the problem. Afaik Valve would be fully within their rights to C&D them from unofficially rehosting their binaries. In any other situation, that would be a blatant security risk.
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. 😁
I’ve always found the most time consuming thing about arch is having to spend half your life telling everyone you use it.
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.
You can install Arch directly from a UEFI shell over the Internet: https://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.Does UEFI shell have wget?
The important question is if the UEFI shell can run Doom.
Of course it can. What did you expect?
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). https://netboot.xyz can also boot other OSes than Arch.
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.
I haven’t used it in years, so hard to remember now.
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.
I was like you using arch packages for everything until ferdium was hit by a terrible bug that broke its zoom function and wont be fixed in months since it is an issue with electron. Now I use the appimage version of it to downgrade to an older version.
And then there are the rust programs that you can only find as aur git packages which means installing a bunch of dependencies and all the crap that cargo puts into my home dir just to build one binary, for that I just instead take the appimage version or sometimes the binary if they release it and place it in ~/.local/bin.
Another good thing is that the appimages get compressed and take less disk space, for example the libreoffice package in arch is 600 MiB while the appimage is 300 MiB.
And the great thing is that I can just drop my homedir into any distro and as long as I make sure that fuse is installed everything will work out of the box.
It sounds like NixOS would solve all your problems. And it makes coffee too!
Still figuring out Nix for my daily driver (too many fun customizations moving away from gnome), but love it so far and built my last self-hosted box with it. So easy to redeploy after the initial learning curve. Boot from ISO, partition with disko, upload SSH key to decrypt sops, install.
Oh and since practically everything can be overridden, its easy to get bleeding edge using existing packages!
Nix is objectively a bad language. Glancing past the syntax (which is atrocious and the parser is completely unhelpful) it’s just a bad idea to mix lazy evaluation and dynamic typing, the only way to get understandable error messages with nix is to put asserts all over the place, hoping one of them gets triggered by the evaluator.
That said I still love the system to bits and fixing the language actually wouldn’t be that hard: Add static typing, with inference most stuff should just run as-is. Exception are the two or three uses of the y-combinator (yes, seriously, that’s how you recurse in nix) deep in the bowels of nixpkgs, e.g. during stdenv bootstrap. Just make
fixa primitive, or maybe a plain fold I don’t think nix even needs to be Turing-complete. Reason it’s not being done is that there’s enough other stuff to work on and, well, Stockholm syndrome. Good news: Nix doesn’t support constructing import paths dynamically, that would have been a nightmare to sort out in a static setting.I don’t mind most of the language having FP experience, but I agree the lack of static typing just sucks. I’m using the repl a lot to try and track down why things aren’t aligning quite right when trying different techniques to keep things DRY and organized. Documentation is also a headache as a newb with the multiple ways of structuring a repo while trying to grok all the implicits and how it all gets merged.
Is NixOS xdg base dir compliant? that is one of the reasons I don’t use flatpak.
Yes, all the environment variables are set automatically and programs respect them.
Yup, the AUR is a godsend. I barely touch the other methods and only use AppImages when I’m too lazy.
Appimages when you’re lazy? The fact you have to chmod them is annoying compared to an AUR helper
I mean Dolphin gives a prompt for the same thing when I launch it.
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).
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.
If you want, or are interested in looking at an easier to manage Arch install I would suggest CachyOS, EndeavorOS, or Garuda Linux.
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.
Maybe they’ll get there eventually, considering this is their method of choice for installing 3rd party apps on SteamOS 3.0.
or, you know, you can use your distro packages
Steam’s runtime is already sandbox-ception. Flatpak might be more appealing to Valve than it seems.
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…
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.
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.
or, you know, you could use a much better and consistent platform
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.
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.nixfloating around you can just copy and adjust and direnv does the rest.
I use debian, I’m happy and definitely have no idea what you are talking about :)
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
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 :)
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.
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.
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 ;)
It’s actually a massive issue on Debian
mmh, what? :)
?
👍🏾
Good. Snap is an abomination.
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.
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.
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.
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.
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
I think they meant that the Snap itself (or part of it) is proprietary. But I’m not sure.
Snap isn’t a standard actually. It’s closed off.
Hence I picked the word “format”.
Every line of snap code that touches your computer is open source, so “closed off” is absolute hyperbole when you are discussing the format
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?
The server is proprietary.
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.
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
Welcome to Linux.
Thanks buddy
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.
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.
I’ve never had an update fail with flatpaks?
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.
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!
If no one else has this issue, it could very well be something unique to my internet connection!
I’ve never had anything like this when I used to run arch (with Archivstall). Also not on fedora for months and now back on LMDE.
How are you closing the program? I don’t mean with the X button on the desktop environment. I mean command line programs.
What program? I just let
flatpak updaterun through until it returns me to my shell.I’m sorry, I must have responded to the wrong comment. That comment was supposed to be in an entirely different conversation.
Edit: Oh, I just reviewed my inbox. I thought you replied to a different comment of mine. I’m so dumb. Carry on.
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?
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.
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).
That’s because years ago you had a choice between using the repo or compiling the package yourself.
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.
Imagine if Fedora came with software specifically made to install and update software from all of those different sources through a simple and unified gui. That would really streamline that whole ordeal. It could even include a snap backend for masochists.
PS
Wait till you learn about nix and guix
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.
The “Discover” app from KDE and the “Software” app from GNOME actually support backend plugins, but it’s far from ideal. I had an issue where a Flatpak (Tor Launcher) showed up in Discover with an update available, but when trying to update it would fail silently and show up as an update again. Updating via CLI revealed that the package was deprecated in favor of another one and it asked whether I wanted to replace it.
Even if it’d work great, it wouldn’t really solve the issue that developers have to try and package their app in many different formats because not all distributions support all formats (out of the box). There isn’t a clear “release in this format” for developers. And as I said, unofficial packages aren’t ideal.
Refer to the xkcd. There’s never going to be a single universal standard to unite them all and in light bind them. The best you’re going to get is improved support and integration.
Obligatory xkcd
obligatory reply to obligatory xkcd
Just tell the billion dollar company to allow people to download the games on their browser. The Client only exists as a means to DRM and analytics, there’s no actual reason for games not to become standalone.
That’s pretty unfair. Before Valve’s efforts, the first thing we PC gamers asked eachother about a new game was always “could you get it running?”
Three bad old days were quite bad, and they started getting better in lock step with Valve’s improvements to Steam.
Correlation/causation and all that. But for a lot of us Valve earned a lot of goodwill simply by allowing “request a refund” on games that run poorly.
Their refund policy is due to getting slapped around in EU courts, not because valve is benevolent or anything. I do like steam a lot, but it is a near monopoly which acts as DRM to a degree. They did and would abuse that power unless regulated.
I believe their refund policy is actually from ACCC in Australia, rather than European rulings
You’re correct, Australia played a big role in it, and the EU was passing regulation around 2015 on that issue as well. So they got slapped around in Australia and changed it up before getting slapped around in the EU.
A lot of people these days have no idea what has happened outside of the few years they’ve been in contact with the industry. Computing might as well have started in 2005 when you listen to them.
As someone who was during those times, your Zgen knowledge is very incorrect. The games did work, including Crisis (original). As to why the myth you hear from fellow Zgen gamers; it’s because graphics cards were invented. Brand new, no one knew what they were doing with them. The companys Renzen and Nvidia started sponsoring games, it’s how they became popular, their logos were part of the game, Metal Gear Solid revengeance is proof of this.
Steam had no part in gaming history, they were not the first online platform. Dell made wild target before Valve Corporation was founded. Lootbox was invented before Steam launched it, Yahoo games (anyone remember them) in japan had the concept down to almost todays standards. Valve had nothing to do with gaming history, they are just known for their lawsuits and anti competitive behavior.
I’m incorrect that my PC games didn’t work on my PC?!
Shit. Thanks for clearing that up.
Your points about Vavle part of the same bullshit are worth raising, though.
But a unified store with reviews, a refund policy, , and installers that actually fucking worked was a really big deal, especially to those of us without bleeding edge hardware - which was most of us.
Edit: and don’t start talking about gaming history to me, I was there for all of it. Pong didn’t come with an installer, it came with the hardware. Turn those paddle knobs folks. Pong is still better than a lot of the shit you kids are playing.
You fake, everyone in the older days knows how the controls work. All except you younger people, you didn’t turn it, you slide it.
https://www.youtube.com/watch?v=FvT8jG1OVdI&tWhat you describe was the Arcade version, not the popular console versions.
Valve is in a lawsuit: https://news.bloomberglaw.com/antitrust/valve-loses-bid-to-end-antitrust-case-over-steam-gaming-platform
Dell did make wild target: https://m.youtube.com/watch?v=ibz8kpsRHdk
Here is an alternative Piped link(s):
https://www.piped.video/watch?v=FvT8jG1OVdI&t
https://m.piped.video/watch?v=ibz8kpsRHdk
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
you didn’t turn it, you slide it.
Like the cx30 on the popular 8 bit home console Atari 2600 which was a knob you turn?
Steam had no part in gaming history, they were not the first online platform.
Lmao. This is like saying the iPhone or iPad had no part in smartphone/tablet history, because neither were first to the market. It’s a ludicrous take.
Valve had nothing to do with gaming history
Lol
they are just known for their lawsuits and anti competitive behavior.
I’m willing to bet this isn’t true lol. Valve is only known for anti-competitive behaviour? Come off it.
The Iphone wasn’t part of touchscreen technology either. They were just the first to try heating sensors. It’s still being used in android devices too. The ability to use physical sensors is gone. Apple killed it off.
Valve is in a lawsuit, do your research next time: https://news.bloomberglaw.com/antitrust/valve-loses-bid-to-end-antitrust-case-over-steam-gaming-platform
Lmao
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.
Agreed. the only “workarounds” I’ve needed to do (on arch) is install
gtk-desktop-portal-{gtk,kde}because it’s not included withkde-plasma5for some reason.
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…?
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).
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
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
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.
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
accessibilityconfusion.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.
Tbh i never found an app that runs better on snap than on deb
Same goes for almost anything like snap
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!
Wait until you find out how distro packaging works
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.
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.
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.
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
isn’t that kind of what AUR is, and exactly what people love about arch ?
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.
How is “the dev of the app” defined, exaxtly?
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.
Ah, that makes sense. Inwas hung up on the word, interpreting it as a single guy, not an entity. Thank you.
deleted by creator
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…
For security reasons the packaging of flatpaks in flathub is done by flathub, whether they are devs or third parties they just write the manifest. Although I seem to remember there are some exceptions, such as firefox.
Ah, I was not aware of that. Ok, that’s good to hear because it potentially adds a layer of security.
Any idea whether they vet the code as well?
Not that I know of. But you may be interested that it requires prior authorization to modify manifests.
Excellent. Thank you
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.
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.
Fedora is the best!
(In my opinion)
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.
Yeah, it’s trash. I switched to the .deb awhile ago because of how bad the snap was.
