your comment on flatpak, snap and appimage?

14 Antworten [Letzter Beitrag]
tonlee
Offline
Beigetreten: 09/08/2014

about these 3 options, do you know about
how they stand on security and
privacy? Which option do you favor?

I know the snap server software is non free. I
would prefer had the server software been free
software. But it is not a free software matter,
because free software is about the license
of the software running on your computer.
I have been leaning towards snap, because I would
expect cannonical having more resources for
providing a secure solution. I do not know about
snap privacy.
About flatpak, I have noticed when you install
the first couple of flatpaks, then some big
software packets gets added. After that installing
further flatpaks does mostly not add more
big software packets. I expect about appimages
you do not get that sharing gain? In terms
of decentralization and program makers not having to
rely on someone else's system appimage is
the better option. Thanks.

Magic Banana

I am a member!

I am a translator!

Offline
Beigetreten: 07/24/2010

I know the snap server software is non free. I would prefer had the server software been free software. But it is not a free software matter, because free software is about the license of the software running on your computer.

The problem is: the Snap Store does not only serve free software and there is no way to setup an alternative server that would have a "only free software" policy. Flatpak does not have that problem: https://docs.flatpak.org/en/latest/hosting-a-repository.html

I have been leaning towards snap, because I would expect cannonical having more resources for providing a secure solution.

Canonical does not have more resources than Red Hat, which now belongs to IBM. Red Hat pushes Flatpak.

https://ostechnix.com/linux-package-managers-compared-appimage-vs-snap-vs-flatpak/ criticizes Snappy, including when it comes to security. I quote:

"On the flip side of things, snaps are widely criticized for being centered around Canonical’s modus operandi. Most of the commits to the project are by Canonical employees or contractors and other contributors are required to sign a release form (CLA). The sandboxing feature, a very important one indeed from a security standpoint, is flawed in that the sandboxing actually requires certain other core services to run (such as Mir) while applications running the X11 desktop won’t support the said isolation, hence making the said security feature irrelevant. Questionable press releases and other marketing efforts from Canonical and the “central” and closed app repository are also widely criticized aspects of Snappy. Furthermore, the file sizes of the different snaps are also comparatively very large compared to the app sizes of the packages made using AppImage."

The same link criticizes Flatpak's security too:

"Flatpak has resulted in widespread criticism of the team’s tall claim of providing a secure framework. The blog (named flatkill) linked at the end of this guide in fact mentions a couple of exploits that were not addressed by the Flatpak team as soon as they should’ve been.[15]"

That said, one should check whether such exploits still work. I would not be surprised if flatkill was motivated by primary anti-Red-Hat-ism (as many anti-systemd sites).

About flatpak, I have noticed when you install the first couple of flatpaks, then some big software packets gets added.

They are called runtimes. They provides basic dependencies many programs need.

I expect about appimages you do not get that sharing gain?

Indeed. A package that uses a runtime is easier to maintain by its developers. As far as I understand, that is the main advantage. Also, with AppImage, I believe that a same library may be loaded several times to RAM, for different programs.

In terms of decentralization and program makers not having to rely on someone else's system appimage is the better option.

That is my understanding too, but relying on runtimes eases their work. Snappy is certainly the worse when it comes to centralization.

MistahDarcy
Offline
Beigetreten: 03/18/2016

I prefer Appimages. With Flatpaks and Snaps you have to download a bunch of extra stuff to get them set up and running, then they pollute your software center with a ton of proprietary garbage - at least that's been my experience on Debian / Fedora based systems.

Appimages remind me of "Portable Apps" on Losedows. Download the app you want, make sure it's executable, and then you're done. Individual programs can push updates through their own servers and if you want to decline an update you can stay on which ever version you have downloaded. Works great for emulators like Duckstation and RPCS3.

nadebula.1984
Offline
Beigetreten: 05/01/2018

It seems that AppImage (formerly PortableLinuxApps) is the least evil among the three.

And it seems that Trisquel (based on oldest Ubuntu LTS) is ideal for AppImage packaging.

andyprough
Offline
Beigetreten: 02/12/2015

I installed a few flatpaks because I wanted to try some advanced features. Especially the newest version of Okular, KDE's PDF document viewer and editor. The latest versions have some special editing features I would like to use. Unfortunately, flatpak had to download a truly massive amount of stuff to install Okular, and once it did, I found that the flatpak version was crippled, especially with no ability to print. Since printing the edited PDFs is one of the primary functions, the package was basically useless.

My other experiences with flatpaks were similar. Very large downloads, and the packages themselves were either slightly or highly crippled making them not worth the trouble.

On AppImages, I use the LibreWolf one, and it is truly a good web browser experience. Uses less resources than any other major browser that I've tried. I'm now learning to extract the AppImage file and alter its contents in order to enhance the privacy of the LibreWolf browser even further. And the LibreWolf AppImage file is actually smaller than the installation files for some distros, such as for Arch. I think the AppImage packaging method shows a lot of promise.

calher

I am a member!

Offline
Beigetreten: 06/19/2015

I rarely have issues with Flatpak. My only complaint is that the usual
repository for Flatpak contains some proprietary packages. I have really
considered making a clone of such a service, but containing only those
packages which can be included in GNU FSDG distros.

name at domain wrote ..
> On AppImages, I use the LibreWolf one, and it is truly a good web browser
> experience.

AppImage is fine, I guess. No standard location to put files, so I end up
putting them in "~/.local/lib/" in accordance with Freedesktop.org.

LibreWolf is not suitable for inclusion in FSDG distros because it asks the
user if they would like to enable DRM. I even went into the [discussion
channel][1] for LibreWolf and asked them if they could make simple changes to be
included in FSDG distros, and was met with much resistance. It seems the
people who make LibreWolf are more concerned with security than supporting
the growth of user rights.

[1]: https://librewolf-community.gitlab.io/

andyprough
Offline
Beigetreten: 02/12/2015

Are you sure? Recent iterations of LibreWolf have DRM completely disabled by default, and no way to enable it without manually rewriting config files. I have not once been offered any kind of option to turn it on. I think you may be thinking of the older LibreWolf project - this current edition is a different team and different code and goals to my understanding. When did your discussion with them occur?

calher

I am a member!

Offline
Beigetreten: 06/19/2015

A month or so ago. Maybe we were both mistaken as to whether LibreWolf still
permitted DRM.

koszkonutek
Offline
Beigetreten: 03/19/2020

I think this topic has been brought up before (but cba looking for it). AFAIK, just having DRM functionality compiled in is enough to be FSDG-incompliant, regardless of whether it is turned on by default and whether there is user inerface for enabling it.

It also seems clear why developers refuse to go further and completely disable support for DRM - they very likely consider the current state of affairs good enough for those users who don't want to run DRM.

What do you think? Personally, I wouldn't mind using LibreWolf but would not like to see it in an ethical distro in its current form

Adrian Malacoda

I am a member!

Offline
Beigetreten: 12/26/2010

The discussion in question is here - https://gitter.im/librewolf-community/librewolf?at=60bdc69819b46c60b1728372 - and predictably, the response seems to be "we're more focused on privacy than on freedom issues" (despite having "libre" in the name...). That's unfortunate but I think understandable, if users in the proprietary world can't get Netflix to work they'd probably rather switch to a less free browser than stop using Netflix.

I think LibreWolf could be used as a base for a fully-libre Firefox, perhaps more easily than Firefox itself. I would like to get something like that into Guix (there is IceCat, which follows ESR; nothing like Abrowser which follows Firefox releases).

calher

I am a member!

Offline
Beigetreten: 06/19/2015

name at domain wrote ..
> I think LibreWolf could be used as a base for a fully-libre Firefox, perhaps
> more easily than Firefox itself. I would like to get something like that into
> Guix (there is IceCat, which follows ESR; nothing like Abrowser which follows
> Firefox releases).

Is there any way we could just get Abrowser built for Guix? I tried, but building
a browser is a lot of work, and I could not figure it out. Mozilla's documentation
on building Firefox expects that you are using version control, not a tarball, and
the build tools will not let you build anything if you are not in version control.

andyprough
Offline
Beigetreten: 02/12/2015

>"What do you think? Personally, I wouldn't mind using LibreWolf but would not like to see it in an ethical distro in its current form"

I use it all the time. DRM is completely disabled and cannot be enabled without me manually re-writing config files. That's clearly a good enough standard for my use. Do I need to cut my nose off because it might someday smell an evil smell? Should I cut out my tongue to make sure it never enjoys any evil drinks? Should I cut out my eyes to make sure I never look at anything evil?

No - this ultra-ultra-purist attitude turns "software freedom" into a "software prison".

I can also load all kinds of non-free software on a Trisquel installation by manually changing a few config files. So by the definition applied to LibreWolf, Trisquel could never be a free distro, because it doesn't completely handcuff the user. Parabola has proprietary software blacklists, which can be changed or disabled by the user making manual config changes. By the definition applied to LibreWolf, Parabola could never be considered a free distro, because it doesn't completely jail the user and throw away the key.

Adrian Malacoda

I am a member!

Offline
Beigetreten: 12/26/2010

I still believe GNU Guix is the best option for a distro-independent package manager (although I prefer using it as a distro itself). Guix:

* respects the GNU free system distribution guidelines
* builds all packages from source
* can be instructed to build from a specific git checkout or with a specific patch
* does not do any containerization/sandboxing natively - some might see this as a negative but I'd rather that be something I can opt into rather than controlled by the package manager.

Avron

I am a translator!

Offline
Beigetreten: 08/18/2020

I like Guix but I am puzzled by the situation of Ungoogled Chromium that it includes. It seems issues were raised about it and they were not full answers, for instance about DRM support.

mmmmna
Offline
Beigetreten: 09/18/2020

I'm using one 'appimage', and it is quite slow to load on an i7. 32 bit Sempron kind of slowness. Too slow, IMO. Once loaded, it works very well, I haven't seen any problems when I run it. It is a huge file for what it does.

I left Canonical's distros because of Snaps. No, thanks, not interested, and despite my removing snapd from 'buntu, the Canonical plan to further the spread of Snaps is not a goal I wish to spread.

So far, that is my 2 cents.