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

2020-06-11 Thread Nicolas George
[ 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 1 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


signature.asc
Description: PGP signature


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

2020-06-10 Thread The Wanderer
On 2020-06-10 at 09:27, Nicolas George wrote:

> The Wanderer (12020-06-09):

What's with the stray 1, here?

>> I subscribe to probably dozens of mailing lists, and I don't know
>> of any way to configure things to add that header with a proper
>> value automatically on a per-mailing-list basis. Otherwise, I'd
>> probably have done this years ago, unless other considerations
>> (e.g., UI for when I want to do this vs. when I really do want to
>> reply to the sender or to all recipients) took precedence.
> 
> With Mutt, I use this:
> 
> send-hook ~cdebian-u...@lists.debian.org my_hdr "Reply-To: 
> debian-user@lists.debian.org"
> 
> There is certainly an extension to Mozilla to do the same thing with
> a few dozen clics.

I haven't found one to date, but I'll look again.

>> For myself, I use the "Reply to List" button in (a now-old version
>> of) Thunderbird, and avoid the issue of Reply-To settings entirely
>> unless I actually do want to reply to something other than just the
>> list.
> 
> That means you need to remember and take notice, each time you reply
> to a mail, whether you are replying to a list or not.

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.

> I personally reject any solution with that requirement, since there
> are solutions without.

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.

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

Imperfect though it is, he use of a separate "reply to list" button is
the least problematic option that's close to a general "usable across
all scenarios" solution that I've seen actually get implemented so far.

That said, as I said above, I'll look into the type of hook you
mentioned, and see whether it produces better results for my particular
case and sensibilities.

>> While I wouldn't necessarily take the argument as far as you appear
>> to, I am inclined to agree in principle.
>> 
>> That said, while this is an important aspect of the situation,
>> it's technically a tangent from the question of whether people
>> other than the developers can build the program and have the result
>> be usable. If we assume that the developers don't routinely update
>> or replace these prebuilt objects, and don't hack these objects
>> themselves as part of working on the project, then the tree we have
>> is the tree the developers build from - and if we can build a
>> working program from it, then that narrower question is answered
>> "yes".
> 
> These thoughts caused me to consider an even scarier hypothesis:
> 
> It's entirely possible that the authors of Jitsi themselves would not
> be able to build it from sources.

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

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature