I welcome AppImage and Flatpak.
In his world developers don't do that, they throw a pile of source files into the wind and let package maintainers put it together for a distribution.
However, there is still a large amount of software out there for which the above does not hold. That software is not currently being installed with a package manager - it is the curl | bash scripts you see all the time, as well as a whole bunch of other more manual methods of downloading and installing. It is this software that solutions like flatpack and snap are for, and it is improving both the security and usability in these cases.
On Mac.
This is mostly a sovled problem on Linux. Hell even slackware has this mostly solved.
I will concede there is a lot of Linux users out there either misinformed or simply don't mind the hassle of upgrading via random curl scripts if at all.
Maybe it will help them? Maybe it will just increase the target size making exploitation more worthwhile / likely?
Who knows.
For me, if it's not in the Arch repos (or aur) I'm incredibly unlikely to install it, to the point I don't actually have any software installed out of band other than stuff I specifically work on.
Massive amount of identical work that the WASTE majority of the time, does not improve anything for the end user.
Security should come from moving into well maintained platform, automatic scanners and many users. Instead of the package maintainers being the 'security reviewers' we should have app stores and sub repositories with security reviews.
Nothing stops a distro from only offering flatpaks from their own repo.
Centralizing and automating these things will allow for far better security processes in the long run.
Just try to do some of these steps on 2-3 versions (versions for non-rolling distributions) of each of the following distributions: RHEL, Debian, Ubuntu, Arch, Gentoo.
The Linux distribution ecosystem is insane.
It's also one of the reasons users and proprietary software have been rare on Linux.
It's also one of the reasons users and proprietary software have been rare on Linux.
It may be why proprietary software is lagging, but I think most users prefer an OS level package manager. They just didn't know about them until the Appstore.
Edit: I have no idea why you think this is condescending.
Package maintainers can also be a bad idea! They have the ability to make the user experience worse and create a lot of unnecessary work for vendors. The version of AbiWord on Ubuntu was out of date and unsupported for a while. There was a steady stream of people going through vendor support channels reporting bugs that had been fixed a year previously. The maintainers ignored the vendor's requests to update the package to a more recent, supported version.
You can't blame distribution maintainers for not wanting to expose their users to a constant stream of the newest exciting quirky features the authors have decided to cram into the current release just to be able to keep on top of all of the bugfixes. New releases all also tend to implicitly have new or different sets of dependencies, and distributors have a duty to make sure these various dependencies that exist in their distribution can coexist and interoperate
Authors declaring whatever versions they no longer care about as "unsupported" is a rather unhelpful trait that ignores where their users are (distributions) and what a lot of their users actually want (stability).
I'm sure developers would ideally like to have users suckling at the teat of their latest tagged changeset and perpetually excited about the latest enhancements in each and every release. But really I'd wager that most people, of the ~20-30 applications and desktop components they use every day, by and large... they'd just like most of them to behave like they did yesterday - or last week - or last month - as long as it's reliable.
Do maintainers commonly audit source code to look for vulnerabilities? And at any rate, aren't the common security-critical libraries for flatpaks, like OpenSSL, already (in theory) provided and maintained by the runtimes?
All the major consumer OSs distinguish between system components, like cryptographic services and graphics libraries, and user-facing applications. The world hasn't collapsed for them so far, and in an ideal world that distinction allows for better delegation of responsibilities.
>The world hasn't collapsed for [major OS vendors] so far
Hell yes it has. Malware and user-hostile is running rampant on the "major" platforms like Windows and macOS. Have you ever used a non-technical person's computer for a few minutes? It's like a warzone.
Flathub isn't trying to replace your package manager for everything, just for graphical desktop apps. As far as I'm concerned, it's more than welcome. I'm tired of hearing about a major release of a desktop app and not having it available for months. Even worse, I'm tired of hearing about a major release, experiencing horrible bugs when the maintainer updates it, and not having any long-term option to install the previous version so that I can get work done.
Flatpak solves all of this and more.
I think there's a vocal segment of the Linux community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications. Don't worry, no one's taking away your apt-get, pacman, rpm, eopkg, makefiles, etc.
I'm sure it could help with application delivery so long as it's constrained to that. I don't want half of my standard libraries or utilities suddenly becoming sandboxed. For full blown applications sandboxing would be welcomed.
[1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
[2]: https://specifications.freedesktop.org/basedir-spec/basedir-...
Problem is they both need to create an area with a full separate file system which doesn’t really fit in with the FHS.
When I ran mount, I noticed that every package I'd installed had it's own entry in the mount list. After I rebooted the machine, these mounts were no longer listed and the software I'd "installed" was no longer available through the gnome menu.
I'm not against finding new and better ways to package software but this experience left me with the expression that the technology is not quite ready to be rolled out and adopted en masse.
Even Linux has had several: NeXTStep style Application Bundles in GNUStep, AppDirs in ROX filer, and AppImage today. They're just not over-engineered enough for the Linux Desktop community to embrace or something.
https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setu...
I'll chase it up with the responsible team.
I go back and forth on this one.
On one hand I think it would make things much simpler for users who have enough storage and bandwidth.
On the other, when there is a vulnerability in a major library we would have to wait for every application to be updated, if they're even being maintained.
The thing is that package managers have mostly abstracted away the headaches of dependency hell, but have also raised the barrier to entry, so any software not participating seems suspect.
There's a vocal segment of the mobile App developer community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications on iPhone and Android phones.
In reality, it doesn't matter.
I saw a lot of near pension age people, first time computer users, being taught basic usage of Ubuntu at around version 5.10. In our office, we have administrative and corporate treasury staff being taught to use it. The matter of them using it and not complaining "where is the start button here?" is having them RTFM* or get fired.
Not a single time we had to fire anybody over that.
Irony here is that the few Windows machines in the office are used by engineering for things like solidworks, different physics simulation packages, cadence, vivado and etc
[*] available in eloquent Chinese, unlike worse than Google translate Microsoft's manuals
There is no value in having a package manager on top of one.
The real problem is that actual software is trying hard to be too complex and violate best practices for installing software.
User managed Apps are okay. But: only for private use and never for company use since user control IS the actual issue there.
well, private use is by far the majority use case, isn't it ?
The rush towards containers because they're "easy" strikes yet again.
My fear is that the handful of companies that build packages for their desktop apps with abandon them and move to Flatpak/Snap. From the Flatpak docs it looks like anyone and everyone can just get access, even if you don't own the thing you're packaging. So if you pack $newpopularsoftware first you can now install malware on everyone's computers with a single push.
It's like they looked at everything bad about Chocolatey/NPM/pip/AUR and just ran with it.
That's an insane thing to say. Literally 100s of people doing the same thing adding no value to the end user. That is a waste amount of resources waste by the open source community.
> My fear is that the handful of companies that build packages for their desktop apps with abandon them and move to Flatpak/Snap.
Good? Why does it matter to you.
> From the Flatpak docs it looks like anyone and everyone can just get access, even if you don't own the thing you're packaging. So if you pack $newpopularsoftware first you can now install malware on everyone's computers with a single push.
Nothing stops you or any distribution from having a repo with reviewed or specially selected software.
Also, the waste majority of packagers would not have found that malware anyway.
Or you know developers could package their own software. It's some upfront effort but usually set and forget. Things like FPM[1] make this even easier. Personally I don't know why developers find packaging so hard, I've had to package hundreds of bit of software for different distros (and versions of said distro) over my career and it's usually set and forget with some changes when there are big underlying changes to the OS like sysv > systemd. Granted my experience is with non GUI apps so I can imagine there is likely some pain points between different distros/version when it comes to the hot mess that is DEs.
> Good? Why does it matter to you.
Because I have to go from trusting 1 vendor to install 1 package (and dependencies) to 1 3rd party repo that anyone can push to. That is a huge change in the trust model.
> Nothing stops you or any distribution from having a repo with reviewed or specially selected software.
We already have those.
> Also, the waste majority of packagers would not have found that malware anyway.
This isn't about trusting the software in the package it's about trusting the package maintainer, who could now be absolutely anyone with no verification or validation. See malware in other user run repos like NPM, pip, AUR etc...
Dude, seriously. Flatpak has issues, but saying "Packaging was a solved issue" when every distro rolls out its own packaging system is the reason we can't have nice things.
Ignoring the problems won't make them go away.
If every distribution was using the same packaging system, would they still be separate distributions?
EDIT: By packaging system I assumed we meant the same repositories, and packages. Since that is how Flatpak seems to work.
But, they don't. Lots use Debian’s, for instance.
What this does is allow software to keep working when a library update happens without having to spend hours/days tracking down wierd scripts you don't even understand and running them as root to fix your problem. Not everyone wants to write OS-level software or fix every bug themselves.
Hell, my GF watched me install something that wasn't in the UI app center (whatever it is called) via command line, and was like, "WTF do you have to do that? That's the most stupid thing I've ever seen." The fact is, she's not wrong.
How does this compare to the traditional package managers?
[1]: https://docs.snapcraft.io/build-snaps/upload
1. Packaged by the developer/publisher, see Virtualbox, Spotify, Chrome, Slack etc...
2. Packaged by a single 3rd party, see PPAs
3. A central 3rd party repo populated by anyone, NPM, AUR, pip, Snap/Flatpak etc..
Case 1: I have to trust the developer/publisher which is sensible, you're already trusting their code to run.
Case 2: I have to trust some random 3rd party, sometimes this is possible, sometimes not but if I do trust them I'm trusting them for one package (and maybe it's dependencies). I may have multiple options of who to trust to provide this package.
Case 3: Anyone can package anything if they get there first they can publish things however they like. The problem is that they are implicitly trusted by the repo, not me.
The first 2 are acts of active trust, I have to verify the person/company I'm downloading and make a decision whether I trust them or not. With a 3rd party central repo (it doesn't matter what format) I do not have that option, I either trust everything that anyone can publish to be correct or I don't use it.
Basically they did just that. The only "desktop" devs left in Linux land are really cloud devs that dabble in desktop on the side. Damn it, i have been basically told to clam up when i complained about the cloud mentality having no home on the desktop. Because apparently only could mattered because it was the big Linux user case.
The Snap store so vastly improves my user experience of using common apps I switched from Arch Linux (where 50% of the programs I had installed came from the AUR) to Ubuntu, where everything I needed was just there. No longer do I need to run weird scripts from the internet to get simple stuff to run on my non-standard distro (which could be Arch, Fedora, or whatever I am running at the time).
You can hold the position that these things are a big security risk. Distributing monolithic packages with likely old/vulnerable dependencies is not a great idea. But on the other hand, it prevents asking the user to run random scripts (which in many cases are not vendor provided) as root to get their software, and it gives the user integrated automatic updates and other software center integration (as opposed to downloading random stuff from the internet). In terms of increased security through sheer usability and requiring less manual maintenance, the advantages of Snaps and Flatpak add up, I think. Many things in security are a tradeoff, and I feel that getting the user to do the right thing is often extremely undervalued. I think it is also undervalued in these comments.
Flatpak and Snaps still have a lot of problems. Why do we have two competing standards? Why can't I properly get all Snaps running on Fedora or other platforms that use SELinux [rhetorical question - I know the technical reasons]? Why do so many apps not use their sandboxing effectively? Why is it so hard for these things to respect my computer's theme? The list goes on.
The list of problems is long and valid. But I think it's worthy of some celebration that advancements are being made in making desktop Linux usable for users and popular for developers. And I don't think it's clear at all that this is a regression in terms of security.
Especially if you are running a non ubuntu distro you are stuck with snap AND something else rather than replacing your current system with snap.
Further both apt and snap are strictly inferior to nix or guix so you are actually stuck with 2 worse packaging systems in place of one superior one.
For what its worth my experience with a ubuntu/ubuntu derivatives was different. I found the non LTS releases fraught with difficulties and the LTS was out of date sufficiently that I ended up adding over 80 ppas to get up to date version which isn't much different than having 80 some aur packages save that it is less convenient.
The real key to Flatpak and Snap is the entire app "experience" - integration in the software center as a trusted source, automatic updates, clean installs and removals without messing up other parts of the system. Before Flatpak and Snap, this did not exist on Linux, especially not in something that was compatible with all distros.
I don't know about that. This "advancement" is catching up to where every other desktop OS was in the 80s.
When you drag-and-drop a file from e.g. a file manager into some application, then the DnD events do not contain the file. Instead, they contain something like `text/uri-list` enumerating the file paths. If you sandbox some app, then you need a bit of software to map and translate these paths. If you do not provide such software, then your sandbox does not support DnD.
Also the Snap store allows a larger range of software (WINE repackages, server apps, duplicates, etc) that Flathub does not. Flathub is also hand reviewed so it takes a bit longer for new apps to get in.
firefox, vscode, etc. there is also this - https://www.docker.com/docker-news-and-press/docker-and-cano...
As an end-user, I want my apps to be getting regular, automatic updates, which means it's vital to get them from some kind of official repo. I sympathize with the one-man developer who just wrote some cool little Electron app that he designed to be cross-platform and promptly gets bombarded by requests from his 10% Linux userbase that wants the app to be packaged for Debian/Ubuntu/Fedora/SuSE/Arch repos. I get it, I've been that annoying guy[0].
So to that end, packaging once as a Flatpak and working everywhere has been great. A handful of those pesky apps I used to have to regularly check for new RPM releases are now on flathub and I can update them automatically.
With that said, flatpak support is still spotty. DNF doesn't support flatpak yet, so I had to install GNOME Software on my Cinnamon DE just to be able to easily support and update them. There's also the issue of the greatly inflated installation sizes. I'm hopeful that support will get better soon now that it's finally at 1.0.
[0]https://github.com/MarshallOfSound/Google-Play-Music-Desktop...
DNF probably won't support flatpak, as it is something entirely different. Gnome Software does support multiple backend thought.
If you want to install/update/remove flatpaks from command line, just use the flatpak command ("flatpak update" will check all the configured flatpak repositories for newer versions and update whatever is available).
Could you not just use the cli?
(Not trying to start a holy war, just a question)
Installing a PDF reader should not forcibly install Udisks2 and upower.
A lot of commenters are upset that maintainers are being removed from the equation. Can't each distro just set up their own maintained repository? If I understand correctly, there's nothing about flatpak that actually prevents traditional maintaining. The only thing distros have to do is integrate flatpak, set up their own repository as default, and note that user should use other repositories at their own risk. Which is basically how things already work.
Is there a valid reason to hate flatpak itself, or are you all just too caught up in hating change to actually evaluate it?
This because they do not want to admit that distros being slow with rolling out new releases of their software, is because of the dependency tangles that they have created for distro maintainers.
I haven't used the feature yet, but supposedly there's a means of easily rolling back to a previous version in case an update has a bug the user can't work around. Rolling back RPM's can be non-trivial when there are many dependencies - it's way easier for me to do rollbacks of an RPM only based system by Btrfs snapshots which of course not everyone can depend on just for undoing an application update.
So I'd say this is definitely an improvement from a user perspective; and it seems no more painful and perhaps a little less painful for packagers.
