Am I the only person who actually doesn't really mind that flatpaks and snaps have less user-control over behavior and/or security implications?
I really enjoy them. Install it, forget about it, let it update automatically.
Theoretically could something unwanted happen, yeah probably, but I enjoy the convenience they provide and typically you're installing fairly well-known software (Microk8s, VS Code, and Chromium come to mind).
My one gripe with snaps is that AppArmor can occasionally cause headaches with Microk8s permissions.
> I really enjoy them. Install it, forget about it, let it update automatically.
This is the same thing that happens when installing from the distribution's package manager? I install it, forget about it, and run the update command whenever I remember, once every few weeks.
The amount of available software depends on your distribution, but on Arch practically everything is available in the official repositories or the user repositories.
And when security issues are fixed, updating my system fixes them for all applications instead of just the ones which update their flatpaks (and from the article, it seems like many don't).
> And when security issues are fixed, updating my system fixes them for all applications instead of just the ones which update their flatpaks (and from the article, it seems like many don't).
Not sure why you'd cite that wiki page, as it describes how Debian maintainers should be removing embedded copies of dependencies and (if necessary) patching the software to use the system versions.
Sure, it's not perfect, and some packages end up having embedded dependency copies, but that's a far cry from flatpak, where everything is an embedded copy, by design.
And which one of them has a better track record pushing out security fixes, especially for older software?
Containers are a security nightmare because developers tend to have a release-and-forget mindset. Packagers are the ones doing the thankless work of constantly tracking issues, backporting fixes, dealing with dependency issues, etc. Take the packagers out of the equation and the result will be entirely predictable--much more stale software sitting on the hard drives of oblivious users, just as we see with containers.
IMHO this should be thankless. If you want updated software then update it.
By backporting fixes, you create an untested and unsupportable version. They pull patches that may or may not have dependencies on other changes to the software, which they avoid because they don't want to update, and generate a whole bunch of noise for application developers.
No software exists in a vacuum. It's the job of the packagers to create a platform that works as a whole. That's why distributions exist in the first place.
If the upstream releases a new version and the packagers just throw it into the distro, they've created an untested and unsupportable system.
This is true. So stop trying to pull apart tens or hundreds of other people's work hours on some attempt to create some frankenware.
The rest of what you wrote doesn't make sense. Of course it would get tested whether they backport or not. Of it doesn't, then they aren't testing what they are doing now.
The current state is that we don't get much cross pollination as the version being pushed by RedHat isn't the same as the version being pushed by Debian, so bugs are introduced and resolution doesn't help each other.
Your distro doesn't live in a vacuum. Stop acting like it does.
I'm not quite sure what's rubbed you up the wrong way here, but I'll address these points in order:
> This is true. So stop trying to pull apart tens or hundreds of other people's work hours on some attempt to create some frankenware.
I'm not involved in this, so I'm not entirely sure what you want me personally to stop doing, but I definitely appreciate the efforts of distributions to create systems that work together as a whole, and don't spontaneously fail because an upstream author has put out a new release and is now forcing me to choose between carrying a vulnerability and breaking compatibility.
> The rest of what you wrote doesn't make sense.
I beg to differ. Perhaps I should simplify my language.
> Of course it would get tested whether they backport or not.
By whom? There's a reason Debian Stable has a painfully long release cycle, and it's partially because they're taking that time to make sure the complete set of versions you get when you do an `apt-get install <whatever>` works together, as a coherent system. If you change `libfoo-1.0.0` to `libfoo-2.0.0` and just push that out to everyone, the combination of `libfoo` with any of its dependencies or dependents is now untested.
You can make a separate argument for rolling release distros if you like, but the problem doesn't go away.
Again, this is why the concept of "distribution" came into being in the first place: because throwing together arbitrary versions and expecting the result to work is madness. Or, if you prefer, Debian Unstable.
> The current state is that we don't get much cross pollination as the version being pushed by RedHat isn't the same as the version being pushed by Debian, so bugs are introduced and resolution doesn't help each other.
Correct. And if upstream authors took responsibility for their previous releases and backported patches themselves, they wouldn't have divergence in the first place. But that's not necessarily workable, so we've got the next best thing: other people keeping the lights on for them.
> Your distro doesn't live in a vacuum. Stop acting like it does.
> And which one of them has a better track record pushing out security fixes, especially for older software?
given the amount of security issues that are being fixed silently, even sometimes unadvertently, in newer releases of any software, I really believe that doing this instead of forcing ppl to update just creates a less secure world.
Which distribution provides security updates for all their packages for let's say three or five years? Debian Stable has exceptions, so does Ubuntu and it also makes a huge distinction for thousands of packages in the Universe repository, which for the most part don't get any support at all. Fedora releases are AFAIK only supported for a year or two.
And then you also get the issue of bugs that are actually security issues, but weren't labeled/identified as such, and therefore never get fixed in those stable distributions.
According to their git repository[1] the last time they updated the WebKitGTK library was half a year ago. In the meantime there have been multiple upstream releases, fixing multiple security vulnerabilities[2-6]. Or does this git mirror not reflect the current state of the version they're shipping?
Looks like that package is part of the AppStream collection and therefore does not have the same guarantees as the core packages. That's at least what some quick googling told me.
RHEL and CentOS have pretty good backporting support for packages that they support, but most installs of them that I have seen use/include packages from other collections that are not supported, which is of course the wrong way to do it.
Flatpak has a package split into three parts: a program itself, a runtime, and a SDK. Runtime includes common libraries a program is usually required, and SDK includes a development counterpart of them.
Flatpak program is pinned to a runtime version, e.g. org.freedesktop.Platform//18.08 (with 18.08 being a major version) of which receives security updates periodically. When user installed a package, Flatpak will install a program and its runtime to Flatpak directory.
If a program only depends on libraries in a runtime (and not requiring any bundled dependencies) then packager won't need to worry about upgrading those libraries at all, as updating a runtime will update those dependencies.
I just wish they separated out the functionality of app portability, app sandboxing, and app installation. It’s much less debuggable and comprehensible packaged together. Kind of reminds me of systemd, actually.
I don't think you can separate sandboxing and installation. Any nontrivial and useful sandboxing relies heavily on how / where the app lives and how it communicates with the world. This includes things like dbus paths too, not just file paths.
The other way is to rely on labels rather than names. But I don't see every distro switching to selinux with per-flatpak/snap policies, so it's going to be have to be joined installation and sandboxing.
Err, I'm still having issues grasping the problem—why not just enforce portable installation and locally writable files? There's no reason user-facing apps need to be installed to anything other than a subdirectory of home, there's no reason to locate the app resources anywhere but as a subdirectory of the app installation, and the XDG filesystem standards for writing seem pretty solid at this point. You could then restrict all access by default and just prompt when it attempts to use a resource.
I was originally very hopeful for snaps, but my experiences with them have been consistently painful. Whether that's due to a fundamental issue, or just a new ecosystem that hasn't matured yet is beyond me.
If you don't care about user control, why would you be using Linux at all? When you hit a bug in a flatpak or snap, what are you going to do? E.g. on Linux you now just can't input Japanese text in Slack and there's no way to fix this.
I really enjoy them. Install it, forget about it, let it update automatically.
Theoretically could something unwanted happen, yeah probably, but I enjoy the convenience they provide and typically you're installing fairly well-known software (Microk8s, VS Code, and Chromium come to mind).
My one gripe with snaps is that AppArmor can occasionally cause headaches with Microk8s permissions.