Can I ignore flatpak indefinitely?

[email protected]

Sure, here are some:

http://security.stackexchange.com/questions/259088/ddg#270934

https://en.wikipedia.org/wiki/Digital_signature

The main feature would be that if flathub (or a hacker with access to flathub) acted maliciously, digital signatures would prevent them from issuing malware infested updates to flatpaks. Only the software's originator would have the cryptographic key needed to sign releases of the software.

[email protected]

I wasn't being very serious about nix. IMO, it's quite the time investment due to its poor documentation and it has a lot of gotcha's if you aren't on NixOS e.g one example is that it's great for terminal applications, but horrendous for GUI applications as it'll be hit or miss. Again, this is if you're not on NixOS. So, it can feel like an "all or nothing" approach.

If you have the time and will, then it can be very rewarding. But if you just "want something that works " side by side in your current system, personally, I wouldn't recommend it - unless it's hidden by some other tool like devenv (which is a great tool for reproducible developer environments).

Anti Commercial-AI license

[email protected]

I never use flatpaks and am doing just fine. I don't want my packages to be installed from a bunch of different places; I want it all managed by one package manager, which for me is my distro package manager. I've never noticed a problem arising out of not using flatpaks; everything I want is either already packaged for me, or I can make a package myself.

[email protected]

It’s not yet fit to protect from malicious apps, but it still finds some use.

That it is "not yet fit to protect from malicious apps" is an important point which I think many people are not aware of.

This makes sandboxing something of a mixed bag; it is nice that it protects against some types of incompetent packages, and adds another barrier which attackers exploiting vulnerabilities might need to bypass, but on the other hand it creates a dangerous false sense of security today because, despite the fact that it is still relatively easy to circumvent, it it makes people feel safer (and thus more likely to) than they would be otherwise when installing possibly-malicious apps packaged by random people.

I think (and hope) it is much harder to get a malicious program included in most major distros' main package repos than it is to break out of bubblewrap given the permissions of an average package of flathub.

[email protected]

Lol thanks for clarifying your sarcasm.
I can be an airhead at times.

I was actually interested in trying NixOS on a laptop that is gathering dust. I did see a few months ago that there was some drama surrounding the project owner, though. I never investigated enough to understand what that was all about, but I'm less excited about digging into something if it may suddenly end.

? Offline

What do you mean by this? Flatpak definitely solved the Linux distro balkanization problem for application developers without trying to destroy the benefits of having different distros. Having a distinction between system software, utilities, and advanced end user applications does solve a problem.

[email protected]

Same boat. As a user, I greatly prefer everything to come from the repos. However, as a distributor, Flatpak makes so much more sense.

The only Flatpak I have installed is pgAdmin. I looked at the build on Flathub with the idea of porting the package myself but got scared off. It was a maze of Python dependencies running in Electron. That seems like exactly the kind of thing that may be better off in its own sandbox.

[email protected]

no flatpak. chill.

[email protected]

Ok, show me how you compile Emacs 29/30 on a fresh Debian 10 install in a few minutes...

? Offline

So far I have also completely ignored them. From what I understand they technically allow you to install old versions of software, potentially having multiple at the same time. This could come in a clutch when working with stuff like Godot or Blender where constantly upgrading to the latest version would cause issues on bigger projects.
This is the only thing I can see myself using them for, at least in the near future.

[email protected]

Another downside of flatpak is that I don't trust upstream devs to have my best interests at heart, but I trust Debian developers far more. I've seen upstream do some annoying or stupid shit and the Debian maintainers not budging.

I think it was poppler or evince that decided they were going to enforce the no-copy-and-paste bit you can set on pdfs. Debian patched it out. I've seen Mozilla decide they were going to enforce their trademarks. They carved out special exceptions for various distros but that still would have meant you would have to rename Firefox if you were to fork Debian. Debian had none of it. There were many dodgy copyright and licensing problems upstream devs gave no shit about. Debian not including these often eventually but pressure on them to fix this shit or for some replacement to get developed.

[email protected]

If there is nothing appealing on flatpak, then sure. But for me it was really appealing and I still ignored it because you need to download big files at the beggining. But later on i started using it for steam and all because that thing is better staying as user-installed files in some form of permission sandbox

[email protected]

I trust Debian developers far more

i definitely agree with you here

I think it was poppler or evince that decided they were going to enforce the no-copy-and-paste bit you can set on pdfs. Debian patched it out.

This is hilarious and I had to know more. First I found this help page which confirms that evince does have code which implements PDF restrictions, but it says that its override_restrictions option is enabled by default. But I wondered: was it ever enabled by default? And who implemented it?

Here are the answers to these questions:

in May 2005, a redhat employee implemented the restrictions in evince in this commit
in September 2005, a yandex employee added the override_restrictions option in this commit, after discussion in bug #305818
in December 2006, someone opened bug #382700 requesting that override_restrictions be enabled by default
in January 2008, a GNOME maintainer changed the default in this commit in 2008 - but only after someone showed a maintainer that the PDF spec does not in fact require the restrictions to be enforced. (The spec says "It is up to the implementors of PDF consumer applications to respect the intent of the document creator by restricting user access")

I don't see any indication that Debian patched this out during the time when evince had it enabled by default, but I'm sure they would have eventually if GNOME hadn't come to their senses

I’ve seen Mozilla decide they were going to enforce their trademarks. They carved out special exceptions for various distros but that still would have meant you would have to rename Firefox if you were to fork Debian. Debian had none of it.

In my opinion both sides of the Debian–Mozilla trademark dispute were actually pretty reasonable and certainly grounded in good intentions. Fortunately they resolved it eventually, with Mozilla relaxing their restrictions in 2016 (while still reserving the right to enforce their trademark against derivatives which make modifications they find unreasonable):

Mozilla recognizes that patches applied to Iceweasel/Firefox don't
impact the quality of the product.

Patches which should be reported upstream to improve the product always
have been forward upstream by the Debian packagers. Mozilla agrees about
specific patches to facilitate the support of Iceweasel on architecture
supported by Debian or Debian-specific patches.

More generally, Mozilla trusts the Debian packagers to use their best
judgment to achieve the same quality as the official Firefox binaries.

In case of derivatives of Debian, Firefox branding can be used as long
as the patches applied are in the same category as described above.
Ubuntu having a different packaging, this does not apply to that
distribution.

[email protected]

https://lwn.net/Articles/335415/

The evince PDF reader ran into this issue back in 2005. It is now rare to find a distributor shipping a version of evince which implements copy restrictions. Xpdf implements copy restrictions unconditionally, but Debian patched that code out in 2002, and that patch has spread to other distributors as well. In general, as one would expect, free PDF readers tend not to implement this behavior. Okular is about the only exception that your editor can find; it's interesting to note that the version of Okular shipped with Fedora Rawhide also implements copy restrictions by default. Perhaps this behavior is result of the relative newness of this application; as it accumulates more users, the pressure for more user-friendly behavior is likely to grow.

? Offline

apt install build-essential
apt build-dep emacs
wget https://ftp.gnu.org/gnu/emacs/emacs-30.1.tar.xz
tar -xf emacs-30.1.tar.xz
./configure —prefix=/usr/local
make
make install

[email protected]

I see, it was Xpdf where Debian patched it out in 2002.

Also lmao @ the fact that Okular's ObeyDRM option still defaults to true today

(Including in Debian, as their KDE maintainer declined to carry a patch to change it.)

[email protected]

Just use Nix. It can run all the packages on whatever platform. It has the largest repository of software & are some of the most up-to-date.

[email protected]

Did I ask for a command? Give that a try in Debian 10...

[email protected]

But for apps distributed in your system’s package manager, it’s not the devs that are distributing them in every package manager. It’s the distribution itself that goes to each repository, checks and tests the dependencies they need and create the package for the distribution, along with a compiled binary version of it.

When they aren’t offered in the distro’s package manager (or the version is outdated because the distro isn’t rolling release) things become more complicated.

[email protected]

If the distro is rolling release, it can always support the latest software in theory, you’d just need to have the correct package formula, which is exactly what AUR is.

The problem with AUR is just that the author of the package is likely not the author of the software so you should normally check what the script is doing.

agnos.is Forums

Can I ignore flatpak indefinitely?