Support us on Patreon
PayPalWell, 2024 should be interesting for Linux packaging! While many distributions use different packaging formats like deb, rpm and others there's also Flatpak for cross-distro support. But we also have Canonical's Snap - which is going to get improved cross-distro support.
Writing on Mastodon, developer Zygmunt Krynicki mentioned "I will be returning as a snap developer later this month. My main focus will be cross-distribution support. Unlike in the past this will be my full time job. I'm very excited for what is ahead for snaps.". It's interesting to see Canonical paying developers to work on this (and it's a good thing too)!
Pictured - The Snap Store
Packaging is always a real sore spot for Linux, and it leads to a fair amount of confusion. Just like with how many Linux distributions there are there's upsides and downsides to it though of course. You don't get innovation and improvements by always sticking to one single thing, and the power of open source is people can often just work on whatever they want.
Still, it would be nice no matter what distribution of Linux you pick, if we can just tell people to "go here" to get whatever app it is they're after rather than having to do a support-dance to find out their specific distribution and version to see what's available to find out how they can grab something.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
QuoteStill, it would be nice no matter what distribution of Linux you pick, if we can just tell people to "go here" to get whatever app it is they're after rather than having to do a support-dance to find out their specific distribution and version to see what's available to find out how they can grab something.
We already can. The "app store" interfaces like Discover don't care if you're on a distro that uses debs, rpms, or whatever, or if you're pulling snaps from snapcraft or flatpaks from flathub; they'll just present a list of applications and an install button. Packaging formats are only of interest to distro maintainers and angry people on the Internet - end users have no reason to care.
9 Likes, Who?
Quoting: CatKillerThe store apps do not solve this though. They give a nice interface and a way to grab them, but they're still dependent on whatever packaging system they have linked in behind them. Some distros don't have Flatpak at all, some need it manually enabled, some have Snap, some don't have Snap, some have neither and only use deb/rpm etc. It's not even remotely solved yet.QuoteStill, it would be nice no matter what distribution of Linux you pick, if we can just tell people to "go here" to get whatever app it is they're after rather than having to do a support-dance to find out their specific distribution and version to see what's available to find out how they can grab something.
We already can. The "app store" interfaces like Discover don't care if you're on a distro that uses debs, rpms, or whatever, or if you're pulling snaps from snapcraft or flatpaks from flathub; they'll just present a list of applications and an install button. Packaging formats are only of interest to distro maintainers and angry people on the Internet - end users have no reason to care.
5 Likes, Who?
Quoting: Liam DaweThey give a nice interface and a way to grab them, but they're still dependent on whatever packaging system they have linked in behind themJust a small side note (and apologies for being a techgrammarnazi
): Snap and flatpack are not just packaging mechanisms, but these are rather app containerization techs. And this makes them a bit different from rpm/deb/aur/whichever older packaging system.
Last edited by Boldos on 9 January 2024 at 1:50 pm UTC
2 Likes, Who?
Quoting: BoldosOh I am aware of how different they are, but this article wasn't a place to dive into the deep mechanics of them :PQuoting: Liam DaweThey give a nice interface and a way to grab them, but they're still dependent on whatever packaging system they have linked in behind themJust a small side note (and apologies for being a techgrammarnazi
Snap and flatpack are not just packaging mechanisms, but these are rather app containerization techs. And this makes them a bit different from rpm/deb/aur/whichever older packaging system.
6 Likes, Who?
Yeah, I don't mind stuff like Flatpaks for devices like the Steam Deck, where you don't normally get write access to the entire filesystem, but on desktop?
Unless you have a need to sandbox something, just use your distro's packages - they will be compiled with the recommended versions of libraries for the whole ecosystem, instead of storing multiple, slightly different (and potentially way out of date!) versions depending on what you're installing.
Security vulnerability in a shared library? Update it through your distro and you're reasonably well covered across everything on your system. Flatpaks and Snaps? Time to download updates to every single sandboxed app... if they updated at the exact same cadence, if they bother to update it at all. (Yes, it shouldn't mean a *ton* of wasted space as they link and share the same library copy once you've downloaded it once, AFAIK) Almost as bad as all the 'native' apps just using downright ancient, vulnerable versions of Electron for way longer than they should. (*cough* Discord)
It's cool tech, but it should remain specialised, and *definitely* not the first thing you reach for for regular day to day usage, IMO. Heck, snapd was always pretty much the first thing I purged (the Firefox snap was way, *way* underperformant compared to the regular .deb at the time) when I used Ububtu, until I switched distros entirely. You don't *need* to keep five different versions of a library to cover two dozen Flatpaks or Snaps on disk in almost all normal use cases, unless the library update is an API/ABI breaking one.
All that said, one of the biggest criticisms I've seen of Canonical's behaviour is that it feels like vendor lock in, so if it's being opened up to other distros (and it's easy for communities to host their own Snap repos *not* on Canonical's servers), then it's still interesting tech to watch and potentially keep in your back pocket for those situations where it makes sense, so good on them for at least trying, now.
Unless you have a need to sandbox something, just use your distro's packages - they will be compiled with the recommended versions of libraries for the whole ecosystem, instead of storing multiple, slightly different (and potentially way out of date!) versions depending on what you're installing.
Security vulnerability in a shared library? Update it through your distro and you're reasonably well covered across everything on your system. Flatpaks and Snaps? Time to download updates to every single sandboxed app... if they updated at the exact same cadence, if they bother to update it at all. (Yes, it shouldn't mean a *ton* of wasted space as they link and share the same library copy once you've downloaded it once, AFAIK) Almost as bad as all the 'native' apps just using downright ancient, vulnerable versions of Electron for way longer than they should. (*cough* Discord)
It's cool tech, but it should remain specialised, and *definitely* not the first thing you reach for for regular day to day usage, IMO. Heck, snapd was always pretty much the first thing I purged (the Firefox snap was way, *way* underperformant compared to the regular .deb at the time) when I used Ububtu, until I switched distros entirely. You don't *need* to keep five different versions of a library to cover two dozen Flatpaks or Snaps on disk in almost all normal use cases, unless the library update is an API/ABI breaking one.
All that said, one of the biggest criticisms I've seen of Canonical's behaviour is that it feels like vendor lock in, so if it's being opened up to other distros (and it's easy for communities to host their own Snap repos *not* on Canonical's servers), then it's still interesting tech to watch and potentially keep in your back pocket for those situations where it makes sense, so good on them for at least trying, now.
0 Likes
Quoting: KithopYeah, I don't mind stuff like Flatpaks for devices like the Steam Deck, where you don't normally get write access to the entire filesystem, but on desktop?
Unless you have a need to sandbox something, just use your distro's packages - they will be compiled with the recommended versions of libraries for the whole ecosystem, instead of storing multiple, slightly different (and potentially way out of date!) versions depending on what you're installing.
Sorry, but it doesn't work that way and it's not even the main point of these package formats.
Snaps/flatpaks are there to make packaging and distribution easy for software creators and make them independent of distro maintainers who may or may not include a given piece of software, or may be including an ancient version of it.
They are also there for users who now can always have a piece of software available directly from the Snap store or a flatpak repo and have the latest version of it, regardless of whether the distro they use provides it.
Since you use Artix you may think every distro is like Arch where every piece of software ever written is included in the aur, but that is not even remotely the case for the vast majority of distributions. And there are good reasons for that, so there is a space for both.
Last edited by damarrin on 9 January 2024 at 5:28 pm UTC
5 Likes, Who?
Quoting: damarrinSnaps/flatpaks are there to make packaging and distribution easy for software creators and make them independent of distro maintainers who may or may not include a given piece of software, or may be including an ancient version of it.
Totally agree - that is 100% a valid use case for this, and a better way of putting what I was trying to get at: if your distro *does* ship an up to date version, you should use that as your first choice, since it may need to have been customized for said distro, it'll be kept up to date with shared libraries, etc., but if it *doesn't* (and you don't want to go down the rabbit hole of compiling it yourself... I've written my own janky PKGBUILDs for that, in fact, and it's not user-friendly), these are a great fallback.
My issue primarily is that Canonical likes to push the snap version of a package as the first choice, regardless if there's a perfectly valid .deb available, and I think that's wrong, because that pulls Ubuntu even further away from upstream Debian and introduces yet another unique distro-ism when trying to troubleshoot. The cynical part of me worries that 'pulling away from upstream Debian' is their big goal.
That said, it's been a few years since I ran Ubuntu on a desktop - does an 'apt install firefox' still pull in the snap by default? If they've walked that back since, then my argument is invalid and out of date.
1 Likes, Who?
mattaraxia Jan 9
Quoting: KithopUnless you have a need to sandbox something,
You have a need to snadbox *everything* already. I'm blown away this mindset exists.
The purpose of sandboxing is zero days. The whole point is you don't know about them until there's a problem.
For example, there was a nasty bug in steam shortly after launch that could essentially rm -rf / and destroy everything the user had access to. It should be sandboxed. There was a really nasty exploit in Zoom allowing for RCE. It should be sandboxed. There was even a really nasty RCE vulnerability in the library most desktops use to thumbnail common files. Just downloading it and executing nothing could run arbitrary code.
*nothing* is immune. Sandboxing is categorically good.
Also, flatpak absolutely uses shared libraries. This notion that you have to hope every single app updates is fundamentally wrong. The runtimes can also be provided by the distro, like on Fedora, especially Silverblue.
These things need to be embraced. They are the best Linux Desktop security improvements we've had in . . . well maybe ever.
1 Likes, Who?
Quoting: mattaraxiaYou have a need to snadbox *everything* already. I'm blown away this mindset exists.
Ah yes, I'm going to sandbox 'ls' from the filesystem, and then explicitly fiddle to punch holes in to make it useful again...
Facetious and hyperbolic, yes, but let's not get into absolutes here. Sandboxing is great when you want it, but it's most definitely not for *everything*. There is a time and place for it, and I believe there are distros that lean on it extensively. It's great tech, but also *incredibly frustrating* as a user if you're not expecting it. All the Wayland xdg-desktop-portal stuff comes to mind - I love Wayland, but it shouldn't take *three separate popups* to allow OBS or Discord to screenshare a particular app, with no option to 'remember my choice forever please'. We're going to end up with Windows UAC level annoyances again, and then people will just turn it off entirely.
Should apps like Steam be sandboxed from accessing anything outside of ~/.steam (or equivalent)? Sure. Should your browser be sandboxed to not access things outside of your Downloads folder? Sounds like a good starting point. But remember, you may want to preview that PDF from your Documents or a thumb drive, or a static HTML page you're working on off a network drive, so it's got to be easy to do so and yes, explain and understand the implications.
If you want to run a Flatpak or Snap, you should understand that yes, you get sandboxing and the double edge that goes with it in terms of 'why can't this app see my files'. Unless your distro is explicitly designed for it, though, I believe it should not replace your native package manager. If I want to switch, let me make the choice to switch, don't start forcing Snaps on me when I call apt and expect a .deb.
3 Likes, Who?
Cloversheen Jan 10
Quoting: mattaraxiaThese things need to be embraced. They are the best Linux Desktop security improvements we've had in . . . well maybe ever.I think we can agree they like to believe they are. But that mentality not seldom comes from devs that don't really get the full picture. (I'm looking at you FreeGnomeHat
). They have gotten so hooked on their own kool-aid that they tend to loose sight of if what they are doing is actually doing something.As Kithop mentioned above, Wayland and xdg-desktop-portal really comes to mind, do note that pretty much all flatpaks you install have permission=all set for hardware devices. There is a system to filter permissions for hardware for sure, but no-one actually do because that breaks things. This has been the case going back years. You can have a lookie in Flatseal for instance to see the state of affairs, it can be a bit depressing...
And as Kithop also alluded to, this whole thing reminds me of UAC. Good in theory. In practice? Everyone clicked "Accept" so the thingie they want to run can do the thing. And suddenly you might as well not have it. Which is why they massively toned it down after its initial release back in Windows XP.
Now I do agree with you that it is a step in the right direction for certain things. I'm much happier running Steam through Flatpak than through native because then I don't have to deal with lib32 packages and all that. I know how to do it, and I know the pros and cons of doing it from my distro. But the Flatpak experience is pretty darn good for that particular use-case.
1 Likes, Who?
See more from me