[ It comes back to Jitsi and its license after a few paragraphs. And it is appalling. ] The Wanderer (12020-06-10): > What's with the stray 1, here? We are in 12020 HE = 2020 CE, HE stands for Holocene Era, or possibly Human Era, it is just shifted by 10000 from the Common Era. As a consequence, all interesting dates are positive, since there was not much going on earlier than 12000 years ago that would warrant an accurate date. https://www.youtube.com/watch?v=czgOWmtGVGs > Not so much so; when not replying to a message received through a > mailing list, the button is grayed out and unavailable, because there is > no address for it to use. > > So still "notice", to some degree, but not "remember", because the > software handles that for me. This proves my point: this is bad UI design. Instead of disabling the button, it should revert to the non-list behavior. That would allow you to click on it always, without having to take notice. > Don't get me wrong; my original position on this, which I'd still prefer > a solution that makes possible, is that the basic Reply function should > do "smart" detection of the default reply target in all cases. I have > rants written up about what the logic for determining the default should > be, and I suspect that you'd agree with their results. Probably. What I observe is with maling-lists that set the reply-to for subscribers, I can use the G group-reply command and it does what I want more than nine times out of ten. > But I've seen persuasive argument that there's no way to make such > "smart" reply direction detection smart enough that you don't need to > override it in some cases, and that the number of different UI Ah, the classic "we can't make it perfect, let's not make it at all" fallacy. > elements which would be needed to for all the different possible > override types (reply respecting Reply-To, reply to sender, reply to > list, reply-all, reply to list and sender, reply respecting Reply-To > except also include list, ...) would very quickly proliferate to the > point of unwieldiness. This too is quite a fallacy. > FWIW, since I wrote that I've looked at things a bit deeper. (Though not > much.) > > They do, apparently, update the JARs (lib/installer-exclude/) on a > somewhat regular basis; there is a commit under that directory every few > months or so, and most of them involve a commit message which looks > related to updating from upstream. > > The SOs (and DLLs, and .dylib / .jnilib files), on the other hand... the > most recent log entry for the lib/native/ directory is from 2017, and > the ones before that quickly go to 2016 and 2015 and on earlier. These > appear to be mostly put in place and ignored, except when something > breaks. (On the Linux side, only one of the .so files - libunix-java.so > - appears to exist in current Debian testing / stable; that does not > speak well for the possibility of being able to identify the appropriate > upstreams.) Oh, thanks for finding these. It is so much worse than I thought. They are playing fast-and-loose not only with their build process, they are playing fast-and-loose with the licenses of the dependencies and with security. I can even say: they are violating my copyright. They distribute binaries of projects that are distributed under the terms of the GPL, but nowhere have I found the corresponding source code, nor a written offer for it, as specified in article 6 “Conveying Non-Source Forms” of the GPL. I will grant you that they do not do so out of nefarious intent, only negligence. But that negligence shows that they do not understand a significant part of what Libre Software is about. And they are shipping a five-years old FFmpeg binary. In the last five years, a few security-relevant bugs have been fixed in FFmpeg. People, take notice: this is one of the reasons we insist on proper packaging and being able to rebuild from source entirely: to allow security upgrades for the included libraries. Regards, -- Nicolas George
Attachment:
signature.asc
Description: PGP signature