PureOS already includes libappimage0 in the repos. I think that there is an investigation of appimage internally, I’ll try and get more information on that.
1 Like
It’s a store, not a “shop”. The distinction may not matter but store nonetheless has connotations of a warehouse or storage area. The point for Purism is to have a place for apps that meet our critieria and may not be available for Debian.
1 Like
Maybe the term “repository” might be more appropriated? Even if “Store” is much more smartphone-ish, maybe it’s just me but I see “Store” as if there is something to sell (in the case of “free” smartphone stores you sell your privacy to get a service).
You can see also: snaps
Here an example
maybe it’s just a misunderstanding but i tought that flatpack was more of a rpm based distro thing. seeing as ubuntu uses snap and it’s a deb based distro like pureos i figured it would be snap not flatpack.
i miself think it’s a mixed bag of good and bad. an option should be given to the individual user to have the snap/flatpack or just use the classic distribution sistem. an integrated p2p system would be the power option though.
1 Like
My understanding with Snappy is that you have to use Ubuntu’s Snap store. This is just another form of vendor lock-in.
2 Likes
flatpak, snaps, and appimages are all trying to take advantage of Linux kernel features that enable containers. The container format, if properly packaged, can obviate the need for a rpm and debs, and thereby be universal. flatpak does not rely on rpms or use any rpm technology.
1 Like
Flatpak is an incredible new technology and clearly the future of application packaging on Linux. I for one am very happy to see all the work being put into it, and look forward to seeing more and more adoption for it. I long for the day when I can have everything as a Flatpak and reap the benefits. As a long-time Arch user, I’ve already been switching over to Flatpak as much as possible, and am now planning a move to Fedora Silverblue.
The argument being made by OP’s enormous wall of text seems to come down to “distro maintainers are more trustworthy than the app developer”. That may or may not be true (e.g. with something critical like Tor Browser, I’d rather get it directly from the developers). But that doesn’t have anything to do with Flatpak at all. Flatpak is a packaging method. I think OP is actually talking more about Flathub, but even that has Flathub maintainers.
This is just a total non-issue. It’s like saying APT is evil because you could add random third-party repositories and install malware, or Pacman is evil because you could get malware from the AUR.
4 Likes
Sorry for my delayed response.
Sorry, it was not my intention to try to catch you in any way. And you are probably right assuming Flathub could add ARM flatpaks in the future, if they like.
That’s how I understand it, too: flatpaks can bundle any libs the developer chooses. My point was more that flatpaks can be something inbetween bundling everything and bundling nothing.
This could be where we have differing views - I think some bundling might improve the overall situation, whereas I get the impression you find any bundling unacceptable. Not agreeing on this is ok, of course.
Flathub is a separate initiative from Flatpak, so while Flathub probably can/does host runtimes I don’t think it needs to be that way. But I’m not sure who has the final say on what a user can install and where they get it from. I’m no expert, so take this with a grain of salt, but I think that a base set of runtimes are maintained by the Freedesktop.org project. Maybe this ensures some pedigree?
I also suppose Purism will make a PureOS/Mobile runtime which they would control, one that would include things like libhandy and other phone-specific stuff that may not make it into the standard KDE or Gnome runtimes. That would probably be the runtime used by phone apps.
Yes, I think it can actually be better.
In the ideal case, when a vulnerability in a package is fixed, all applications would be immediately changed to use the new version of the lib. This may often happen, but as the WebkitGTK example shows we can’t always count on it. Applications development may be stalled for some time, or the new version can’t be used due to other API changes, or there are dependency conflicts, etc.
The package repositories have served us well, and still do, but it remains a fact that distros have been carrying stale libs and applications despite security or other issues having been fixed in newer releases. (Also, let’s face it: any change to the code is potentially security related, not just the ones flagged as fixes for vulnerabilities.)
So, this is where I prefer some applications to use the fixed libraries as soon as possible, rather than all applications using the vulnerable version until everything is updated in the repo. My net attack surface may be smaller this way, and meanwhile (if I’m really lucky) Flatpak sandboxing will help contain the apps using broken libs.
No. There’s definitely a risk that applications will keep using bad libs out of convenience, or lack of knowledge, because they just keep functioning. I don’t know what mitigations are planned or in place to counter this. I just hope there will be something.
I’m not sure I fully understand, but yes, malware authors enjoy the same “run on all distros” convenience that application developers get. So it’s easier to target many distros. Still, I find very little comfort in relying on distro differences for protection from malware.
Also, in principle I think getting a random application from some Flatpak repository is about the same as getting it from a PPA. In both cases bad libs could be bundled with the application.
In conclusion, I think both Flatpak and the traditional repo model have their place. Neither is a perfect solutions, neither is inherently evil.
Flatpak tries to solve a number of issues for distros, developers and users: portability, sandboxing, avoiding shipping old versions of applications, etc. It still has to deliver on its promises, but there is too much good stuff to ignore it.
The other day Bryan Lunduke was talking about running ancient software for nostalgia reasons.
I wondered if the solution could be to maintain cross-distro long-time compatibility runtime layers. Like
/usr/lib/rt2012-i386/
If needed, a newer one can be added, possibly based on some Ubuntu LTS release.
/usr/lib/rt2018-amd64/
Seemingly, this is what the steam runtime already does. I think I read criticism about it being outdated, but I’m not sure if that was just meaning “old” or “missing security fixes”.
But in theory, maintaining several such layers (including security fixes) would be possible, and it would be beneficial for several use cases like steam, nostalgia exploration, flatpaks, ppa, possibly some containerization projects…?
Does that sound reasonable?
1 Like
Maintaining old code is not unreasonable, but it is expensive. The question becomes where is the best place to put resources and for a company like Steam I think it may make sense to invest in old games because they were cool and there’s interest. I don’t know if there is the same level of interest in PureOS, at least at the moment.
Not in general, but in this case I was thinking bigger than just PureOS. 
Hence I wrote “cross-distro long-time compatibility runtime layers”
As there are many use-cases, it should be possible to have such layers maintained by several interested parties. And one such layer (from steam) already exists.
2disbetterFeb '19
I think Linux enjoys the freedom from many viruses and malware for the reason you mention but also because of its relative obscurity in the consumer marketspace. For one the hacker community is normally a bunch of script kiddies looking for low hanging fruit. Linux is not low hanging, and the people that gravitate to it are usually a bit more savy than your average computer user.
However, should Linux ever go mainstream, as is the goal of Purism, it will no longer fit into this paradigm. People love to bash on Windows because of the lack of ethics in some of Microsoft’s business practices, etc., but Windows in general is the primary target of all malware in existence. That is a targetword counter the likes of which Linux has never had to bear. And should it, I think you worry about embracing flatpack is going to be small peanuts indeed.
My point being that, as the phone is FOSS based, you don’t have to use one flatpack if you don’t want to. Load up your own repos and go to town.
I agree, I look forward to another such great article. Thank you!
1 Like