Can Trisquel 11 *please* replace Pidgin with a 21st century chat client?
- Inicie sesión ou rexístrese para enviar comentarios
Can Trisquel 11 *please* replace Pidgin with a 21st century chat client? Pidgin is widely recognized as obsolete. It doesn't support Matrix accounts, which makes it totally obsolete in my world, and a bunch of the proprietary IM accounts it claims to support don't even exist anymore. Even core XMPP folks like the core maintainer of Prosody/Snikket dev doesn't recommend using Pidgin, especially not with its janky OMEMO encryption support. IRC chanops also complain about the weird behaviour Pidgin causes when people use it to join their channels
I am a translator!
Can Trisquel 11 *please* replace Pidgin with a 21st century chat client?
Many other clients are in Trisquel repositories so perhaps you mean "default client"?
I don't find pidgin so usable but I am not sure about advertising a default client because:
- there are many single protocol clients
- different clients focus on different types of usage or feature
- different people have different expectations which will result in radically opposite judgement on the same client
- for voice or video with the same protocol, dfferent clients may not be interoperable
Last but not least, many clients change rather quickly and if one has issues and asks on the support channels, the first reply is "your client is too old".
For xmpp, my usage is individual and group chat, both encrypted or not, with file sharing, I don't use audio or video. I use gajim. After having tried versions from guix and flatpak, having run into problems I could not solve, I reverted to trisquel's version although I had to clear my whole history for that. Now, if anyone tells me my client is "too old", I answer that I will stick to the version of my distribution because it won't break, while developpers don't care when the flatpak or guix thing does not work anymore on trisquel following some update.
My suggestion would be not to have pidgin installed by default, improve https://trisquel.info/en/wiki/chatting and link to it.
EDIT: I tried matrix but found it more difficult to use and to host than xmpp.
I am a translator!
I'd like to further discuss how to update https://trisquel.info/en/wiki/chatting. I put some thoughts and welcome feedback.
1) Clients
I could not find Kadu, aMSN or emesene in Trisquel repositories, are there still there? If not, let's remove them from this page.
Tkabber still exists but the link goes to a Russian only page. There is a wiki with partial English translation at https://chiselapp.com/user/sgolovan/repository/tkabber-wiki/doc/tip/wiki/en/Tkabber_FAQ.md but it looks highly incomplete. I guess we should either keep tkabber in the trisquel wiki and link this page or remove it from the trisquel wiki.
Dino should be added to the list of course.
2) Matrix
I suppose it could be added, the trisquel clients I know are nheko (supports encryption, seems functional), spectral and quaternion (no encryption).
3) Adding jami
I would add it with explanations that it works well between laptop/desktop computers but one should not expect mobile phone clients to be reachable easily.
4) Features
There is incomplete text:
1. Which features do I want?
1. plain text messaging
2. voice calls
3. video calls
2. Which operating systems do my friends use?
1. x y and z are multi-platform
3. Which messaging protocols do my friends use?
Do we try completing it? Including by listing clients on non-free OSs?
5) Servers
Do we indicate servers in trisquel repositories?
Do we refer to other projets like freedombox? That project relies on Debian but as far I understand, it only installs things from Debian main. Without the new policy on firmware from Debian, I would have said that the project is compatible with the FSDG, now I would tend to say it isn't.
Ideally, freedombox would be used on trisquel but I expect this not to entirely work and I have no spare computer to test this (unless Olimex boards that are apparently not supported by trisquel unfortunately) and virtual machine testing looks difficult.
Avron:
> Many other clients are in Trisquel repositories so perhaps you mean "default client"?
Correct. Even not having a default chat client, would be better than misleading people into thinking that Pidgin is fit for use.
> I tried matrix but found it more difficult to use and to host than xmpp
How long ago? It's been in pretty active development over the last few years. Did you try any homeserver packages other than Synapse? I hear Conduit (Rust) is fairly feature-complete now, and much more efficient than the Synapse prototype (Python).
I am a translator!
> How long ago? It's been in pretty active development over the last few years. Did you try any homeserver packages other than Synapse?
I did not have problems to install or run Synapse but when I tried joining a public matrix group with self-hosted account, it took several minutes while for an xmpp public group of similar size with a self-hosted account with ejabberd on the same machine it took a few seconds.
I tried matrix clients less than 1 year ago. In Trisquel repositories, nheko seems to be the only functional graphical client supporting OMEMO. It looks generally ok but that makes me think that perhaps matrix isn't mature enough and I wonder why people want to develop one more protocol to do the same like an existing one (xmpp).
I tried a bit with Fluffychat on my contact's iphone. At first, I found the side-channel verification nicer than xmpp with omemo but there were persistent messages of clients being untrusted that I could never get rid of. Perhaps I did not understand how it works.
Avron:
> when I tried joining a public matrix group with self-hosted account, it took several minutes while for an xmpp public group of similar size with a self-hosted account with ejabberd on the same machine it took a few seconds.
I suspect you're not comparing apples with apples. For one thing, did the XMPP group load its history? AFAIK matrix rooms are capable of reconstituting a full room history, not just from the originating homeserver where the room was started, but from any homeserver with members participating in the room. This makes them much more resilient than a MUC, which dies the second the originating server goes down.
> In Trisquel repositories, nheko seems to be the only functional graphical client supporting OMEMO.
This is not a fair way to evaluate bleeding edge software. Unless someone is doing the work to backport never versions, the ones in the repos for each Trisquel version lag behind the Ubuntu LTS it's based on, which lag behind the Debian stable that's based on. Debian maintainers are infamous for lagging behind the releases coming directly from app devs, which is why hacks like AppImage, Flatpak, Snaps etc exist.
> perhaps matrix isn't mature enough
It's certainly not as mature as XMPP, but as shown by my example of public rooms and your example of side-channel verification, matrix apps currently offer many affordances that even the most modern XMPP ones don't.
> there were persistent messages of clients being untrusted
That would be because either you or the person you're chatting with (or both) haven't verified all the sessions you've used to login to your matrix account. Each app on each OS is a distinct session, and there are a bunch of tools for verifying new ones from trusted ones, deleting disused ones etc. This is important, because if an adversary manages to login to your account, or your correspondent's, your encrypted communications are compromised, and that's something I expect you'd want to know.
I am a translator!
> For one thing, did the XMPP group load its history?
In my recollection it did load some history (probably limited to some point in the past) but perhaps it did not come immediately.
> AFAIK matrix rooms are capable of reconstituting a full room history, not just from the originating homeserver where the room was started, but from any homeserver with members participating in the room.
Good to know. However, I prefer a fast join over getting that. I have rather limited interest in chat history.
> This is not a fair way to evaluate bleeding edge software.
I compare what is in trisquel repositories, so older versions of xmpp clients with older versions of matrix clients. Isn't that somehow fair?
After having tried using guix or flatpak, I concluded that I don't want to do that anymore because they don't necessarily integrate well with trisquel and I have problems that I could not solve.
Would you recommend any client in parabola repository? (you can look at parabola.nu and search for matrix in packages). This should be recent versions.
> matrix apps currently offer many affordances that even the most modern XMPP ones don't
Like what? So far, xmpp seems to be pretty suitable for my usage but I am curious.
> there are a bunch of tools for verifying new ones from trusted ones, deleting disused ones etc.
Do you know of any easy description for them? I felt rather lost.
Here's a serviceable overview of matrix features and what they can do:
Avron:
> I prefer a fast join over getting that. I have rather limited interest in chat history.
Fair enough. There's probably a setting somewhere in most clients for toggling that. If not, maybe file a feature request?
> I compare what is in trisquel repositories, so older versions of xmpp clients with older versions of matrix clients. Isn't that somehow fair?
Maybe, but I don't think it's a representative way to evaluate any end-user app with regular releases. Trisquel only gets a new version when it makes it into Ubuntu LTS, which only gets it when it makes it into Debian Stable, which only gets it once it's been through Testing. That's a lot of lag. In my experience, even GNU packages like Jami often have such old versions in the Trisquel repos they don't function reliably. I usually add the public release repo for apps, except for the few that tend to keep up, like Abrowser.
> Would you recommend any client in parabola repository?
TBH I've only tested Element Web and Element Android, and a couple of forks of each (eg Hydrogen on Web, SchildiChat on Android). I don't know if the available matrix web clients pass the LibreJS test, but they seem to work fine in a current Abrowser on Trisquel for me. In theory, it's trivial to host your own, since they don't store any data, but I haven't tried it myself yet.
I am a translator!
> In my experience, even GNU packages like Jami often have such old versions in the Trisquel repos they don't function reliably.
Jami only works reasonably well with jami on desktop computers, it does not work well with mobile phones. I have the version from jami repository because I do testing but in my recollection, the version of trisquel 11 was not noticeably worse.
I use gajim from trisquel repository and had less problems with it than with newer versions.
> I've only tested Element Web and Element Android, and a couple of forks of each (eg Hydrogen on Web, SchildiChat on Android). I don't know if the available matrix web clients pass the LibreJS test, but they seem to work fine in a current Abrowser on Trisquel for me. In theory, it's trivial to host your own, since they don't store any data, but I haven't tried it myself yet.
Both in trisquel and parabola repositories, nheko is the most functional desktop client. I have not used it much but it looks ok, so I would tend to recommend it.
For Android, is Element using a kind of integrated chromium like the desktop version or is it relying on webview?
when it makes it into Ubuntu LTS, which only gets it when it makes it into Debian Stable
Unless that has changed, Ubuntu is based on Debian Testing.
My understanding is that it's based on testing, but has a bunch of packages from unstable and experimental thrown in, and obviously a lot of Ubuntu's own special brew of packages as well.
Magic Banana:
> Unless that has changed, Ubuntu is based on Debian Testing.
This certainly makes sense for non-LTS releases. You may have caught me making an unwarranted assumption about LTS releases. But if I was Ubuntu, I would be basing those off the most recent Debian Stable, since I presume that would reduce the work involved with the longer term maintenance.
Are you still doing paid community management work for Snikket?
https://trisquel.info/en/forum/snikket-flagship-chat-app-xmpp
Wow - I feel as if I've been "community managed" by strypey. If strypey's bashing of the default program is part of paid employment to promote Snikket there seems to be better ways than negative campaigning about how bad other programs are. (Plus a disclaimer would be helpful just like in the past thread.) I have other thoughts too but I don't plan to do strypey's job for them.
jxself:
> If strypey's bashing of the default program is part of paid employment to promote Snikket there seems to be better ways than negative campaigning about how bad other programs are.
Reporting the testable and widely-reported limitations of an app is not "negative campaigning", any more than reporting bugs is. From a user POV, it's a bug in Trisquel that it's recommending an obsolete app - with many obvious functional flaws and an appalling UX - by making it a default. I've been a member of this community for about a decade and pointing out this bug is, as usual, done as a contribution to this community.
> a disclaimer would be helpful just like in the past thread.
See my reply to Prospero. The suggestion that my complaint here is a veiled attempt to promote another app that once paid me for a little bit of work is a) completely nonsensical, since Snikket doesn't even have a desktop client yet, and b) conspiracy theory. Seriously jxself, I expect this kind of thing from the drive-by posters, but this is beneath you.
One other point...
jxself:
> If strypey's bashing of the default program is part of paid employment to promote Snikket
... then why on earth would I mention matrix? Which is Snikket's most obvious competitor? I'm really quite hurt by these allegations :(
I apologize for making assumptions of your motivations. Your long-standing involvement in this community is evident, and I should have given your words the consideration they deserved, rather than jumping to conclusions. I do use Pidgin and it meets my needs for XMPP chatting. Do you have a concrete program to suggest as a Trisquel default? If not, it may be more productive to come up with one. I think the proper way to raise that up to the Trisquel developers would be via the Issues link on the right side of the website. My vote would be that any such change to defaults, if it were to happen, should not be for Trisquel 11 since that's already been released as a stable version and swapping out the defaults on people might not be appreciated but instead for the upcoming Trisquel 12.
jxself:
> I apologize for making assumptions of your motivations.
I really appreciate this, and especially how quickly you posted it. Thank you :)
> I do use Pidgin and it meets my needs for XMPP chatting.
Fair enough. I'm not proposing to remove it from the repos. Just to stop promoting it to newbies by making it the default.
> Do you have a concrete program to suggest as a Trisquel default? If not, it may be more productive to come up with one.
At this point, my vote would be for not having a default chat client. Different people are looking for very different things from chat software. Plus, as I pointed out in my reply to Avron, modern chat UX requires features that app versions in the Trisquel repos are often lacking, because they generally lag well behind development.
Alternatively, perhaps we could offer a selection? The best of breed from the repos for IRC, for XMPP w/OMEMO, and for matrix. Ideally, with the latest versions actively backported before release, and throughout the maintenance cycle. I'm aware that's a bunch of extra work. But perhaps people who like using each of these chat protocols on Trisquel might be willing to volunteer to be trained as backport maintainers?
The ideal solution would be a multi-protocol client like Pidgin. Perhaps there's some way the Trisquel community could support the Pidgin devs to bring their codebase into the 21st century (incl. adding feature-complete matrix support)? Or perhaps another app with a better UX (eg Dino) to become multi-protocol?
This is my most speculative suggestion, as I imagine there are very good reasons why Pidgin dev has fallen behind the times, and why no multi-protocol challenger has emerged to replace it. I'm curious about what Purism are currently doing for PureOS. I know they were at one point funding a developer to work on SMS (and possible matrix) support for LibPurple for their touchscreen device.
> My vote would be that any such change to defaults, if it were to happen, should not be for Trisquel 11 since that's already been released as a stable version
Sorry, that was an error on my part. As you say, such a change would be more appropriate for Trisquel 12, and that's what I was meaning.
"Snikket" makes me think of the Snickers candy bar, which makes me hungry. If we had it as the Trisquel default, it would ruin my diet.
Pidgin is good, because it makes me think of pigeons, and I've never wanted to eat a pigeon.
I think Snikket could use a name change. Maybe "blobfish". It fits, because blobfish's are notoriously chatty. We might have to fork it if the lead dev does not agree.
"The Call of Cthulhu" would also be a good name for a chat client. Calling and chatting are closely related activities.
prospero"
> Are you still doing paid community management work for Snikket?
I did a few hours paid work for them in late 2020. As it happens, I still owe Matt some hours, and recently agreed to write some blog posts for the website to make him whole. Your point?
Had I been proposing Snikket as a replacement for Pidgin, I certainly would have mentioned it. I didn't because it simply isn't relevant to my observations about the inadequacy of Pidgin as a default chat client. Observations that ought to be obvious to anyone who's actually tried to use it recently (do any of you?).
I've been associated with Snikket on and off for a couple of years. But I've been a member of this community in good standing for about a decade. It's a little disappointing to discover that my every comment related to the subject of chat is now looked on with suspicion, because I got paid for a little bit of work, for one Free Code chat project.
Dino is in the Trisquel repos for XMPP. I can get Cinny and Fluffy Chat from Flathub for Matrix if I want. I can get an App Image of Session. Just saying one has options when using Trisquel.
prospero and I installed the Briar client on Trisquel 10 and chatted with each other. So Briar is a possiblity.
True. And both of us testified under oath that Briar Desktop as it stands is a conspicuous resource hog:
https://trisquel.info/en/forum/new-dawn-briar-briar-desktop-050-beta-28-june-2023#comment-173276
At least there is a beta GNU/Linux client for Trisquel users to install and try. As a Gajim fan, I may still vote for it as default XMPP client (even though they list FreeBSD under the "Linux" category).
PublicLewdness:
> I can get Cinny and Fluffy Chat from Flathub for Matrix if I want.
There are 4 matrix clients listed in Add/Remove Applications in T11; Quaternion, Revolt, Spectral, and nheko. I installed them all last night, but I haven't tested them yet.
I finally got around to testing the 4 matrix clients listed in Add/Remove Applications in T11. None of them were fit for production use:
* Nheko: the login screen is unclear about which info goes where. When I put my full matrix ID where it says "matrix ID", it crashed as soon as I put clicked on the password field or the device name. When I only put @username I could put data into the other fields, but I never managed to login.
* Quaternion: seems to have no encryption support. Now that all Direct Message chats are encrypted by default in Element, this makes it unusable as a daily driver. The UI looks like something from the late 1990s, with lots of little windows popping up here and there. Which is fine if you like that sort of thing, but...
* Revolt: Appears to be a wrapper around the Element web client, optimised for a GNOME desktop. Was able to login and verify the session from another client, and messages started decrypting. But it's way too slow to use. It's name is now being used by revolt.chat, a centralised chat platform that aims to be a Free Code clone of Discord. It also uses the names Riot and Element in different parts of the UI.
* Spectral: seems to have no encryption support, and almost no user-facing options of any kind.
I also tried Fractal on another laptop currently running LMDE (as I've misplaced by WiFi dongle and can't use Trisquel on it with WiFi). I was able to login, but it also seems to have no encryption support.
I am a translator!
I know no one who uses matrix, so hard to test, but at least I had no problem to connect with nheko and it seemed functional. I will try again.
By the way: if you have backports activated, gajim 1.4.7 is now available. It is not the last version but its interface is similar to last versions (at least, the difference with 1.8.1 that I see in Parabola is not obvious to me). Many thanks to Ark74.
Avron:
> I know no one who uses matrix, so hard to test
Anyone who wants to test matrix is welcome to message me;
@strypey:matrix.iridescent.nz
... and/or you might like to join the VOICE* testing group;
#VOICE:matrix.iridescent.nz
VOICE hasn't run a test since the pandemic kicked off, ironically, but there are still plenty of Free Code voice chat options to be tested if anyone is keen (including Snikket<>Snikket, and Snikket<>other XMPP apps).
* VOICE Organized Investigation of Chat Engines; https://write.as/zk9vm8m00eutn
Some comments in the fediverse asked what versions I tested. The only Trisquel version supported right now is Nabia (11). Here are the current versions in the Nabia repos for each app I tested, according to;
https://packages.trisquel.org/
* Nheko: 0.6.4 (latest stable release is v0.11.3)
* Quaternion: 0.0.9.4c (latest stable release is 0.0.95.1)
* Revolt: Not even sure, see;
https://packages.trisquel.org/nabia/revolt
* Spectral: Again, not sure, see;
https://packages.trisquel.org/nabia/spectral
More recent versions/ reboots may be available in Aramo (Trisquel 12), which is currently in beta.
FYI According to Hubert Chathi, an Element team member who helps package matrix apps for Debian;
> spectral is abandoned. NeoChat is its successor. It recently added encryption support, so it may be a while before that makes it to the various distros.
https://social.uhoreg.ca/display/11447bcd-1665-430a-c893-81b773420212
There's no sign of NeoChat in a packages.trisquel.org search. Which is odd, because it appears to be packaged for both Debian and Ubuntu. Maybe it only made it into Ubuntu more recently than the version Aramo is based off?
Hubert also said;
> That nheko issue could be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025385 which is fixed in the latest version of nheko.
https://social.uhoreg.ca/display/11447bcd-8065-43a9-6134-e68331060262
It would be great if a more recent version of Nheko could be backported for Nabia and Aramo.
PS Silmathoron mentioned;
> FluffyChat is also available as a flatpak and works decently.
https://floss.social/@silmathoron/111341897181321894
No sign of that in packages.trisquel.org either.
Quick note,
- Nabia is T10 is an "old stable" LTS release
- Aramo is T11 is the latest LTS Stable release.
- T12 is yet to be named as its development will start around early 2024, so nothing here.
And as anyone will expect, 2023-2024'ish software (T12) will be newer than current 2021-2022 based T11 release.
End of note.
Kia ora Ark47, thanks for the corrections. In due course, I will correct my posts here and on the fediverse accordingly. This is a good reminder to triple-check my facts before I make public posts :P
Eg I can't remember whether I've updated my Trisquel laptop to Aramo or not. I will check (triple-check!).
> And as anyone will expect, 2023-2024'ish software (T12) will be newer than current 2021-2022 based T11 release
... and yet because our OS constantly receives updates (as long as we are using a support version), a newbie isn't necessarily going to be expect app software to be many versions out-of-date.
Nor are they necessarily going to know they have to resort to ugly hacks to get up-to-date versions (adding repos, AppImages, FlatPaks, Snaps, etc). And TBH, this is the one area where the HX (Human eXperience) of Windows and MacOS has always been streets ahead of GNU/Linux; the latest versions of apps can be easily downloaded and installed on any supported version of those OS.
How much this matters depends on the app. Some apps receive very few changes between versions, or the changes are mostly cosmetic, which means older versions can be used without issues. Other apps, like Jami and SyncThing, are highly dependent on people using fairly recent versions to work reliably.
So is there a way that we, as the Trisquel community, can improve this for our OS? Or a way the Software Freedom community can improve this for all GNU FSDG OS? For example, running our own equivalent of FlatHub, containing only 100% Free Code apps, and using only Free Code software to run it. Is anyone aware of a project like this?
I am a translator!
I like how https://wiki.parabola.nu/Rolling_vs._LTS phrases it:
You will often hear people disparaging LTS distros with words such as: "out-dated" or even "ancient"; but such labels are vacuous. Realistically speaking, in many cases, "ancient" is referring pretentiously to something that is merely "two years old"; but more importantly, in nearly every case, the software being dismissed is still perfectly adequate and applicable to every purpose for which it was designed. That is precisely the attractive strong-point of "long-term support"; and the maintainers of those distros take great care to ensure that their software is continuously reliable and remains vital for several years. It is far more accurate to view LTS distros as more like a fine wine improving with age, and less like a bowl of fruit requiring constant attention and replenishment in order to remain desirable.
It is a common misconception that "newer" is "better". That may be true generally for hardware; but it is rarely the case for software. When it comes to software, it would be more correct to say that "newer" implies "less mature", and therefore "potentially buggy". It is not uncommon for one of your favorite programs to be broken in some way for days, weeks, or even months when using a Rolling distro; a situation which would be extremely rare when using an LTS distro. For this reason, a Rolling distro can only be sincerely recommended as an "everyday" system in cases where the user knows for certain that a newer version of some software is absolutely required for some extraordinary reason. Even then, it is usually possible to compile and install the newer version of that one program or component on an LTS operating system, keeping the rest of the system in a stable state; rather than replacing the entire system with one of the more volatile Rolling release systems.
Sticking to older versions means it will never break. Perhaps you don't appreciate the value of the older versions until a piece of software you rely heavily on is broken and, because it has upgraded all your files to the new version, you can't use any of your stored files even with the older version that works.
I am using freedombox, including with backports. Freedombox puts things in backports sometimes every week, there are bug fixes and improvements but also new bugs and sometimes it takes the services down and you need to figure out how to repair.
> this is the one area where the HX (Human eXperience) of Windows and MacOS has always been streets ahead of GNU/Linux; the latest versions of apps can be easily downloaded and installed on any supported version of those OS.
This may have some truth. However, I have bad memories of Windows updates, it wasn't that smooth at all. Also, I just switched to Trisquel Mac computers that have no support anymore although they are far more recent and powerful than my X200 and T400.
Sticking to older versions means it will never break. Perhaps you don't appreciate the value of the older versions until a piece of software you rely heavily on is broken and, because it has upgraded all your files to the new version, you can't use any of your stored files even with the older version that works.
You put it in a nutshell, thank you Avron!
When the wiki says;
> It is a common misconception that "newer" is "better". That may be true generally for hardware; but it is rarely the case for software. When it comes to software, it would be more correct to say that "newer" implies "less mature", and therefore "potentially buggy".
This may be true for OS components, like the kernel or window manager, and perhaps some command line tools. Perhaps it was once true of software in general. But in 2023, it is demonstably *untrue* of user-facing, graphical apps. I came to the forum today to report an example of this.
On my other laptop, running Mint LDME, I set up the default mail client (Thunderbird) to connect to my email host over IMAP. It. Just. Worked.
Then I tried to do the same thing on Trisquel. My laptop is running Nabia, the older of the two currently supported version of Trisquel. According to the Parabola wisdom above, this would give me better software.
Opening the default email client, I was presented with IceDove, a package deprecated by Debian when Stretch was released in 2017. 6 years ago.
IceDove was able to find the IMAP configuration for my email vendor, but was unable to login. I'm presuming that unlike the up-to-date version of Thunderbird on LMDE, IceDove was unable to detect that my email vendor requires my explicit approval to allow an IMAP connection. Unlike Thunderbird on LMDE, which redirected me to the workflow required to give that permission, IceDove just guessed "probably wrong configuration, username or password". Wrong, I checked and the configuration and my login credentials are exactly the same used by Thunderbird to login successfully.
So what next? On the right side of the screen was text saying "need help?" with links saying "Setup documentation" and "Support forum". Both links point to non-existent pages at; https://support.mozilla.org/
This older variant of Thunderbird is clearly *not* better than the up-to-date version I'm using on Mint.
Avron:
> Sticking to older versions means it will never break.
This too, is demonstrably untrue. As I pointed out in the very comment you're replying to, older version of P2P software like Jami and SyncThing often break when trying to communicate with up-to-date versions.
> Perhaps you don't appreciate the value of the older versions until a piece of software you rely heavily on is broken and, because it has upgraded all your files to the new version, you can't use any of your stored files even with the older version that works.
I have been using Trisquel as my day-to-day OS for most than a decade, and Ubuntu for a few years before that. I have never once had an experience like this. It sounds like the sort of experience my Windows and MacOS using friends have.
Trying to gaslight people into believing that very real problems don't exist, is disturbingly common on this forum, and in software freedom circles in general. I'm still here, working towards doing all my computing without any proprietary code, because I'm *very* stubborn. Most people, faced with this persistent denial of serious HX problems in Trisquel that need fixing, would have given up long ago.
> Then I tried to do the same thing on Trisquel. My laptop is running Nabia, the older of the two currently supported version of Trisquel. According to the Parabola wisdom above, this would give me better software.
> Opening the default email client, I was presented with IceDove, a package deprecated by Debian when Stretch was released in 2017. 6 years ago.
I don't know about the Debian's Icedove, but Trisquel's Icedove is just as up-to-date in both releases, Aramo and Nabia as any other LTS distro or most point release distros for that matter.
Test 'apt-cache madison icedove' and you'll find one of the following depending on your release.
- icedove | 1:115.4.1+build1-0ubuntu0.20.04.1+10.0trisquel21 | http://archive.trisquel.org/trisquel nabia-updates/main amd64 Packages
- icedove | 1:115.4.1+build1-0ubuntu0.22.04.1+11.0trisquel21 | http://archive.trisquel.org/trisquel aramo-updates/main amd64 Packages
You might like to check you are receiving updates correctly, as Abrowser(/Firefox) and Icedove(/Thunderbird) they both track the latest releases available, not some 6 years old package.
> > Sticking to older versions means it will never break.
> This too, is demonstrably untrue. As I pointed out in the very comment you're replying to, older version of P2P software like Jami and SyncThing often break when trying to communicate with up-to-date versions.
I think Avron tried to imply «stable» old versions, will not break. Jami is not an example of an stable package, it is under heavy development moving the release base ahead when possible, I know that because I have tried to follow their step and it becomes really hard really quick to do that under a frozen LTS. At some point I think they'll reach some stability state and the development will plateau, then we might get a working package with full features that doesn't require to be the bleeding edge one, but that depends very much on the development team plans. I have never used SyncThing so, I won't comment on that.
> Most people, faced with this persistent denial of serious HX problems in Trisquel that need fixing, would have given up long ago.
I'm clearly biased on this subject, but I think Trisquel does a great job doing what it does, being an fully free stable LTS distro providing an easy and popular based option so users can do move into freedom relatively easy.
There is plenty of work to be done, no denial there, each upstream release has its own surprises, also be sure that while it may fit most users, it won't do for all of them as the diversity of needs become just too broad for just one distro if you target all possible users. Thankfully there are other fully free distros out there, Parabola, Hyperbola, Pure OS and so on, that could provide what users don't find on Trisquel.
Leaving the above aside, I've seen more participation on the gitlab instance lately, and while we could always use a couple of experienced hands on the development team, I'd like to thank all users that have gone the extra mile to help present issues in a clear and detailed way so we can act on them, that have updated the documentation or wiki with new or more detailed information, also to all who participate on the forums and finally to all of you that donate or keep donating every once in a while.
If that keeps growing Trisquel could aim for at least another 20 years starting in 2024 :)
Regards
"Trisquel does a great job doing what it does, being an fully free stable LTS distro providing an easy and popular based option so users can do move into freedom relatively easy."
I wholeheartedly subscribe to that. It totally sums up why I have been using Trisquel since Belenos, the only exception being that I am also using Trisquel Mini on an ever enduring netbook.
I have not been using Pidgin for ages, but this now sounds like a totally unrelated topic.
"...and MacOS has always been streets ahead of GNU/Linux"
I had to add my experience here, as I disagree with this 100%!
GNU/Linux is so far superior to macos where updates are concerned (as well as everything else), I couldn't start to cover it.
Over there you feel like you are in a fighting ring. To make it short, the only way to configure YOUR system to suit YOUR work and YOUR personal life, is to stay behind, further and further behind, which the corporation in charge disagrees with and starts a quiet a war to make YOU 'obey'. Glad to say I never did, but being happily behind put me in troubled waters. I must confess I got up and went thanks to the 'kind' hackers (quakers :) who closed that door for me.
GNU/Linux, Trisquel in particular, feels like coming home... I also love the fact that updates and upgrades are paced and considered, it's a marvel!
Sunny Day:
> GNU/Linux, Trisquel in particular, feels like coming home... I also love the fact that updates and upgrades are paced and considered, it's a marvel!
I agree. I've been using Trisquel as my day-to-day OS for over a decade, since the Amazon Lens debacle pushed me away from using Ubuntu. In most ways, it's far superior to Windows, and it compares better and better to MacOS over time, as Trisquel gradually improves and MacOS is gradually enshittified.
> I had to add my experience here, as I disagree with this 100%!
Your comment suggests you are disagreeing with something I never said, which would be obvious if you hadn't quoted that fragment of my comment out of its context. Which was;
> Nor are they necessarily going to know they have to resort to ugly hacks to get up-to-date versions (adding repos, AppImages, FlatPaks, Snaps, etc). And TBH, this is the one area where the HX (Human eXperience) of Windows and MacOS has always been streets ahead of GNU/Linux; the latest versions of apps can be easily downloaded and installed on any supported version of those OS.
To install the latest version on Windows or MacOS, I go to the download page of the app, get the latest version, and install it. Job done. There's no denying that this is simpler for people to understand and to do. It's a fact that it's much more complicated than this to install the latest version of an app on Trisquel.
Now, to be clear, I'm not arguing that installing software using random files downloaded from the net is better than having a package manager to install and update apps. I don't think it is better.
What I'm saying is that we need to come up with ways of getting more recent versions of user-facing apps into the Trisquel repos for the currently supported versions. Which is why I made the suggestion about setting up a fully libre replacement with FlatHub, to be used with FlatPak. But this is just one idea, there may be better solutions. Let's find them and make them happen.
Hi strypey, good to hear we agree on this one:
"Sunny Day:
> GNU/Linux, Trisquel in particular, feels like coming home... I also love the fact that updates and upgrades are paced and considered, it's a marvel!"
I agree. I've been using Trisquel as my day-to-day OS for over a decade, since the Amazon Lens debacle pushed me away from using Ubuntu. In most ways, it's far superior to Windows, and it compares better and better to MacOS over time, as Trisquel gradually improves and MacOS is gradually enshittified."
I also agree with your choice of word for MacOS diminishing usability, "enshittified", not so gradually though :)
As for your next comment, I agree to disagree 100%:
"> I had to add my experience here, as I disagree with this 100%!
Your comment suggests you are disagreeing with something I never said, which would be obvious if you hadn't quoted that fragment of my comment out of its context. Which was;
Nor are they necessarily going to know they have to resort to ugly hacks to get up-to-date versions (adding repos, AppImages, FlatPaks, Snaps, etc). And TBH, this is the one area where the HX (Human eXperience) of Windows and MacOS has always been streets ahead of GNU/Linux; the latest versions of apps can be easily downloaded and installed on any supported version of those OS."
The fragment I quoted is a detail of the whole, not to exclude anything you said, but to add what was missing, the aftermath. If we are talking about updates and ugly hacks here, we would gain by covering all update scenarios, here and there, to be able to put it all in context.
You were talking about the availability of up-to-date software and the ease of finding and installing the newest stuff available, I see that, and that IS the problem because of how this is done in the corporate computing world, there is no comparison, as the "ease" ends there and you might not be able to restore a broken work flow or figure out even uglier hacks to revert to what once worked for you.
Those easy updates can irreversibly brake what you need if you don't take serious precautions. My solution was to have many versions of the system and many clones of each system version. Now, how can a user do that as easily on a laptop without having to resort to acrobatics?
I can't compare what I had with what I have now, this is a completely different world and am grateful for having the opportunity to use libre software that works! Thank you all, the brilliant people who donate your time and skills to make Trisquel what it is!
---
Edit - Was interesting to read what you said about the possibility of "setting up a fully libre replacement with FlatHub". I don't have enough experience to comment, but, as a user, I want to thank you for the suggestion!
> "setting up a fully libre replacement with FlatHub"
This has been an on-going discussion since at least 2016, as mentioned in the links posted by jxself in the first comment of the thread andyprough linked to in a previous comment soon to be lost in the bowels of this thread:
https://lists.nongnu.org/archive/html/gnu-linux-libre/2016-04/msg00070.html
https://lists.nongnu.org/archive/html/gnu-linux-libre/2016-04/msg00116.html
The only thing that is still missing to solve that well-known problem is volunteers to set up that separate Flatpak repository committed to include free software only: "Is anyone interested in doing work on this?"
>"The only thing that is still missing to solve that well-known problem is volunteers to set up that separate Flatpak repository committed to include free software only: "Is anyone interested in doing work on this?"
Would you end up with something that's offering any better software packages than Guix already does?
>"To install the latest version on Windows or MacOS, I go to the download page of the app, get the latest version, and install it. Job done."
Except for all the thousands of programs that are made available as zipped archives, portable apps, java binaries, or that require specialized versions of .NET or special registry hacks or specialized hardware such as expensive graphics cards to run at all. Or that will only install with homebrew or chocolatey or pip or whatever other random and untrustworthy package managers are all the rage with Windows fans lately. If you exclude every corner case, which is a vast amount of software, then yes, installing software from random untrustworthy strangers as an .exe download from random and untrustworthy websites is at least theoretically "simple" on Windows, as long as you are willing to run massive "security" suites to protect yourself against the constant malware and zero day exploits. And pay no mind to the millions of bug reports for the vast number of instances when software simply does not work, since no one is really testing or taking any responsibility for most of it, especially not Microsoft.
I'm not disagreeing with you, just clarifying there is a difference between the over-simplified fantasy version of the Windows software ecosystem and the reality.
>"Which is why I made the suggestion about setting up a fullecosystemeplacement with FlatHub, to be used with FlatPak. But this is just one idea, there may be better solutions."
Guix does provide you with access to 26,779 packages if you install it as an extra package manager. That's all libre software. Not a bad option.
andyprough:
> Guix does provide you with access to 26,779 packages if you install it as an extra package manager. That's all libre software. Not a bad option.
Maybe not, but it's yet another example of ugly hacks that most people will not bother with, because they are not software freedom purists like us, and have work to do and/or lives to live.
Guix is not available in Add/Remove Programs. So installing it is beyond the computer skills of the the 95% of people.
sudo apt install guix
E: Unable to locate package guix
sudo apt search guix
Not a sausage. So AFAICT it's not even in the Trisquel repos. So that puts it beyond the computer skills of 4 of the remaining 5%. Not an accessible solution.
If Guix is a better way of installing up-to-date packages that Apt, maybe that ought to be the default package manager in future releases?
Also, in answer to your comments on the "reality" of installing software on Windows and MacOS, you can argue until you're blue in the face that the water falling from the sky isn't really rain, and maybe you're technically correct. But that doesn't stop you or anyone else from getting wet. In other words, if you have to resort to edge cases to make your argument, then you're proving my point. Which is that installing up-to-date apps is, generally speaking, easier to understand and to do on those OS than on Trisquel.
This is a problem we can fix. So we can we can spend our time and energy coming up with ways to convince ourselves it isn't really a problem. Or we can use that same time and effort discussing potential solutions and their pros and cons, so we can fix it, vastly increase the number of people able to use fully libre distros.
>"sudo apt install guix
E: Unable to locate package guix
sudo apt search guix
Not a sausage. So AFAICT it's not even in the Trisquel repos."
Which Trisquel are you using? My Trisquel 11 has Guix in its repos.
$ apt search guix
Sorting... Done
Full Text Search... Done
cl-consfigurator/aramo,aramo 0.14.0-1 all
Lisp declarative configuration management system
guix/aramo 1.3.0-4 amd64
GNU Guix functional package manager
libhts-dev/aramo 1.13+ds-2build1 amd64
development files for the HTSlib
$ sudo apt-get install --dry-run guix
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
guile-3.0 guile-3.0-libs guile-bytestructures guile-gcrypt guile-git
guile-gnutls guile-json guile-lzlib guile-sqlite3 guile-ssh guile-zlib
libgcrypt20-dev libgit2-1.1 libgit2-dev libgpg-error-dev libguile-ssh13
libhttp-parser-dev libhttp-parser2.9 liblz-dev libmbedcrypto7 libmbedtls-dev
libmbedtls14 libmbedx509-1 libssh-dev libssh2-1-dev nscd
Suggested packages:
guile-3.0-doc libgcrypt20-doc libmbedtls-doc libssh-doc
The following NEW packages will be installed:
guile-3.0 guile-3.0-libs guile-bytestructures guile-gcrypt guile-git
guile-gnutls guile-json guile-lzlib guile-sqlite3 guile-ssh guile-zlib guix
libgcrypt20-dev libgit2-1.1 libgit2-dev libgpg-error-dev libguile-ssh13
libhttp-parser-dev libhttp-parser2.9 liblz-dev libmbedcrypto7 libmbedtls-dev
libmbedtls14 libmbedx509-1 libssh-dev libssh2-1-dev nscd
0 upgraded, 27 newly installed, 0 to remove and 0 not upgraded.
...
@strypey - >"For example, running our own equivalent of FlatHub, containing only 100% Free Code apps, and using only Free Code software to run it. Is anyone aware of a project like this?"
We discussed earlier this year that there is a "floss" subset of flathub that you can set as your flatpak repo.
Here's the thread:
https://trisquel.info/en/forum/why-does-trisquel-offer-flatpak-package-its-repos
The relevant discussion to the "floss" flathub subset starts about here and runs for the next ~25 comments:
https://trisquel.info/en/forum/why-does-trisquel-offer-flatpak-package-its-repos#comment-173362
You'll want to scan through all ~25 of those comments, as there are various flatpak commands that will make it easier to use the "floss" subset. I'm putting "floss" in quotes, because some of the software wouldn't qualify under the FSDG. For example, I think chromium is in that subset, and some "Google Play" package, and probably some others that wouldn't pass muster with the Trisquel devs.
andyprough:
> there are various flatpak commands that will make it easier to use the "floss" subset. I'm putting "floss" in quotes, because some of the software wouldn't qualify under the FSDG. For example, I think chromium is in that subset, and some "Google Play" package, and probably some others that wouldn't pass muster with the Trisquel devs.
My head hurts just reading this. Imagine if this was the kind of advice we had to give people wanting to use Ubuntu in freedom, instead of "just install Trisquel". It's good that there's an ugly hack available to fix this for the more persistent of us, and I'll probably use it. But it doesn't change the fact that we need a general-purpose solution for people who lack the knowledge, skills and/or time for complicated work-arounds.
>"My head hurts just reading this."
Sorry about that. Could be a lack of hydration, or of salt.
>"Imagine if this was the kind of advice we had to give people wanting to use Ubuntu in freedom"
I wouldn't tell an Ubuntu user to use Flatpak, as I personally do not like Flatpak. Far too bloated for what it does, some packages don't have their full functionality in their flatpak versions, many flatpak packages are abysmally out of date, and many flatpak packages are made by random strangers who have no relationship to the projects they are packaging. It's like the IBM-ified version of the AUR; Massive and inefficient.
Whatever happened to empathy?
https://wiki.gnome.org/action/show/Apps/Empathy?action=show&redirect=Empathy
I have a vague memory that at some point it felt like a promising replacement for pidgin, before it unexpectedly slipped into the void.
EDIT: it has been moved to the Gnome attic: https://wiki.gnome.org/Attic/Empathy.
prospero:
> Whatever happened to empathy?
I thought for a split-second you were talking about the state of social media :P
As for the GNOME chat client, I believe it has been abandoned in favour of Fractal (matrix client): https://wiki.gnome.org/Apps/Fractal
> I thought for a split-second you were talking about the state of social media :P
I confess I was, albeit tangentially only, since we are supposedly talking about chat clients. GNU/Linux desktop chat clients for XMPP, to be precise. The main options on Trisquel are Pidgin, Gajim and Dino, since Empathy has been relegated to attic curiosity for the little people long ago.
No idea how many Trisquel users fly Pidgin for anything else than XMPP, but maybe someone could make a detailed study of those three contenders and show us the resulting comparison...matrix?
For the sake of completeness, it may be added that some of the old irrelevant stuff is to be removed from Pidgin 3. So maybe the pidgin should be given further examination before shooting it down on the basis of unverified rabies claims.
The complete state of the winged creature is available here, and here is the part about removing antiquated stuff. The corresponding slide is attached below. Even seasoned archeologists understand that not everything can be retained forever.
| Anexo | Tamaño |
|---|---|
| State_2022_Q4_p13.pdf | 39.36 KB |
- Inicie sesión ou rexístrese para enviar comentarios