[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reply semantics, yet again (was Re: Zoom- best practice?)

[ 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.


> 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"

> 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

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.


  Nicolas George

Attachment: signature.asc
Description: PGP signature

Reply to: