Installing Delta Chat on Trisquel

10 risposte [Ultimo contenuto]
strypey
Offline
Iscritto: 05/14/2015

Hi Trisquelers, what's the best way to install Delta Chat on Flidas? Considering both software freedom issues *and* the security risks of using encrypted comms software if it can't be auto-updated by the package manager.

The downloads page ( https://delta.chat/en/download ) offers:

* Flatpak: I've seen various criticisms of the Flatpak model here. Not sure what the current consensus is.

* .deb: This will work, but it will mean I need to manually download a new .deb every time there is an update. Correct?

* AppImage: Same issue as the .deb, unless there have been some advances in the ability of AppImages to notify users of a new version and initiate an update from within its UI?

* Build from AUR: Uhh. Eh? Is this an Arch thing? I don't use Arch BTW ;)

Thoughts?

nadebula.1984
Offline
Iscritto: 05/01/2018

Of course the deb packages. If you choose to use any of the other package formats, you still have to manually download and install every time.

strypey
Offline
Iscritto: 05/14/2015

nadebula.1984:
> If you choose to use any of the other package formats, you still have to manually download and install every time.

I thought that Flatpak could function like a package manager and perform updates to packages installed with it. Is that not correct? Or do you just mean that such updates are not automatically carried out as part of the usual apt update/ upgrade?

chaosmonk

I am a member!

I am a translator!

Offline
Iscritto: 07/07/2017

The proper solution, assuming that this is a worthwhile package, is for distros to package it. It looks like the backend is already in Debian,[1] with the frontend presumably to follow. However, given the slow rate of Trisquel development, it could be a long time before this package trickles down from Debian to Ubuntu to Trisquel, unless someone backports it.

In the meantime,

> .deb: This will work, but it will mean I need to manually download a new .deb every time there is an update. Correct?

Correct.

> Build from AUR: Uhh. Eh? Is this an Arch thing?

Yes, it's an Arch thing.

> Flatpak: I've seen various criticisms of the Flatpak model here. Not sure what the current consensus is.

Flatpak is harmful (in my opinion, which I won't derail the thread by expanding on here) at a broad ecosystem level, and if you find yourself constantly using Flatpak, then there may be an underlying problem with your distro, with the software you are using, or with your computing habits, but using it for one free software package that you have inspected yourself is not the end of the world.

[1] https://packages.debian.org/bullseye/libdeltachat0

strypey
Offline
Iscritto: 05/14/2015

Chaosmonk:
> Flatpak is harmful (in my opinion, which I won't derail the thread by expanding on here) at a broad ecosystem level

Can you link to anything on the web that explains why you think this?

> if you find yourself constantly using Flatpak, then there may be an underlying problem with your distro,

The problem with my distro is that it's regularly released at least a couple of years behind its upstream LTS, so if I don't find workarounds, it often leaves me dependent on obsolete and even broken version of apps (eg the issues I've raised here with Jami). Given how many user-facing apps are now available for GNU/Linux, and how often they are updated, this is a difficult problem to solve for any distro, particularly volunteer-driven ones, which is precisely why workarounds like AppImage, FlatPak, and Snaps have emerged. Until the software freedom community comes up with a better solution at a broad ecosystem level, it's likely the use of such workarounds will only increase.

chaosmonk

I am a member!

I am a translator!

Offline
Iscritto: 07/07/2017

>> if you find yourself constantly using Flatpak, then there may be an underlying problem with your distro,

> The problem with my distro is that it's regularly released at least a couple of years behind its upstream LTS, so if I don't find workarounds, it often leaves me dependent on obsolete and even broken version of apps (eg the issues I've raised here with Jami)

Yes, that is a real problem, and one of several reasons that I no longer use Trisquel. If users can't rely on Trisquel to generally provide up-to-date and high quality packages, then they are forced to get into a habit of going out-of-repo. The more often they go out-of-repo, the less meaningful it is that Triqsuel's repo contains no non-free software. I might go as far as to say that the freedom differences between Debian main and Trisquel, while they exist, are outweighed by Trisquel's other problems.

> Given how many user-facing apps are now available for GNU/Linux, and how often they are updated, this is a difficult problem to solve for any distro, particularly volunteer-driven ones

It's really not a problem for most distros. Several issues compound in order to create Trisquel's unusual situation:

(1) It is based on an upstream with a 2-year release cycle. This is a pretty good release cycle for enterprise use or production servers, but for typical desktop use it is a little too slow. This is why in addition to its LTS releases Ubuntu has 6-month releases for users who need more up-to-date software.

(2) As you know, Trisquel lags well behind Ubuntu releases. A 2-year release cycle might be tolerable on its own, but due to the lag, instead of your software always being 0-2 years old it is 2-4 years old.

(3) Whereas Debian has maintainers for all of the packages in its free repository, Ubuntu only has maintainers for one of its free repositories: Main. The other (and much larger) free repository, Universe, is not maintained. That means no one is generally backporting bug and security fixes to most of Trisquel's packages. A two-year-old Debian package is missing two years of new features, but has been receiving bug and security fixes. A two-year-old package from Ubuntu Universe could still be suffering from up to two years worth of bugs.

Debian and Ubuntu each only have one of the above problems, which is not ideal, but all three problems compound to make Trisquel's situation far worse.

> which is precisely why workarounds like AppImage, FlatPak, and Snaps have emerged.

You may be using them as workarounds for Trisquel's problems, but that's not why those things exist. Those three packaging formats, though they have many similarities and overlap in features, emerged to meet different use cases. AppImage is the most focused on portability (the ability to transfer binaries on a flash drive was a design goal), and is great for things like beta builds that you want to test with out installing. Snap is a remedy for (3) described above. Flatpak is more similar to Snap than it is to AppImage, but has nothing to do with (3), as Fedora and RHEL don't have that particular problem. Based on what I've read from the people behind Flatpak, that seems to be the one most consciously attempt to shift to a developer-centric distribution model like that of proprietary platforms.

>> Flatpak is harmful (in my opinion...

> Can you link to anything on the web that explains why you think this?

I made a brief comment here[1] with some of my thoughts. If you'd like me to go in more detail let me know. The last few times I've written a long reply to one of your questions here I didn't receive a response. That's totally fine, I know you only check the forum occasionally, but I don't want to spend a lot of time writing something else if there's a good chance you won't see it.

https://trisquel.info/en/forum/ubuntu-snappy#comment-152933

lutes
Offline
Iscritto: 09/04/2020

I have been using a Trisquel 8 + guix combination when people needed rather recent versions of some stuff but wanted to make sure they would not be mistakenly erring on the proprietary side.

Trisquel 9 has now lifted the need for guix but this is most probably temporary. I am considering uninstalling the concerned software and installing it through guix instead in order to avoid running into the same tedious duplication problems when the situation arises again.

I really thought guix would be the safest escape route from the problematic sides of Trisquel, even though it cannot be the answer to every request: https://support.delta.chat/t/request-port-desktop-client-to-some-other-platform/1179.

strypey
Offline
Iscritto: 05/14/2015

The more I hit brick walls with this kind of thing, the more tempted I am to just use and recommend vanilla Debian. The reasons for not listing it as FSF-endorsed seem increasingly impractical, petty and unimportant.

chaosmonk

I am a member!

I am a translator!

Offline
Iscritto: 07/07/2017

I didn't see this until after I posted my other comment, or I would have instead written a short reply to this one. I think you're right, and recently came to the same conclusion.

GNUser
Offline
Iscritto: 07/17/2013

If it was for me, I would use the deb file, and add their RSS feed to my reader so I would be notified everytime a new package came out. A script could be written to automatically download and update the package.
They also have Mastodon and Twitter/Nitter accounts if you choose to follow them there in order to be notified about new packages coming out.

EDIT: Btw, if you would offer a review based on your experience with the software it would be great. I assume you are now using both the Android and Desktop version, correct?

Sasaki
Offline
Iscritto: 08/11/2014

I run Debian 10 alongside Trisquel 9 and I switch whenever I need a recent version of my software, or greatest security.

If it was for me, I would use the deb file, and add their RSS feed to my reader so I would be notified everytime a new package came out. A script could be written to automatically download and update the package.

That's a nice idea. I will do it. Here are the feeds :

- Website : https://delta.chat/feed.xml

- Mastodon : https://chaos.social/[at]delta.rss

I like the new image blur feature.