Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #223087 > unrolled thread

Zoom- best practice?

Back to article view | Back to linux.debian.user

Contents

  Zoom- best practice? Peter Ehlert <peter@sdi-baja.com> - 2020-06-05 18:50 +0200
    Re: Zoom- best practice? Paul Johnson <baloo@ursamundi.org> - 2020-06-05 18:50 +0200
      Re: Zoom- best practice? Peter Ehlert <peter@sdi-baja.com> - 2020-06-05 21:20 +0200
        Re: Zoom- best practice? Seeds Notoneofmy <notoneofmyseeds@gmx.de> - 2020-06-07 20:30 +0200
          Re: Zoom- best practice? Nicolas George <george@nsup.org> - 2020-06-07 20:40 +0200
            Re: Zoom- best practice? <tomas@tuxteam.de> - 2020-06-07 21:00 +0200
              Re: Zoom- best practice? Nicolas George <george@nsup.org> - 2020-06-07 21:00 +0200
                Re: Zoom- best practice? Seeds Notoneofmy <notoneofmyseeds@gmx.de> - 2020-06-07 21:20 +0200
                Re: Zoom- best practice? tomas@tuxteam.de - 2020-06-07 21:20 +0200
                  Re: Zoom- best practice? Brian <ad44@cityscape.co.uk> - 2020-06-07 22:10 +0200
                    Re: Zoom- best practice? <tomas@tuxteam.de> - 2020-06-07 22:30 +0200
                      Re: Zoom- best practice? Brian <ad44@cityscape.co.uk> - 2020-06-08 00:20 +0200
                        Re: Zoom- best practice? <tomas@tuxteam.de> - 2020-06-08 01:00 +0200
                Re: Zoom- best practice? Seeds Notoneofmy <notoneofmyseeds@gmx.de> - 2020-06-07 21:20 +0200
                  Re: Zoom- best practice? Nicolas George <george@nsup.org> - 2020-06-07 21:30 +0200
                    Re: Zoom- best practice? Nicolas George <george@nsup.org> - 2020-06-07 21:40 +0200
                      Re: Zoom- best practice? The Wanderer <wanderer@fastmail.fm> - 2020-06-07 21:50 +0200
            Re: Zoom- best practice? Brian <ad44@cityscape.co.uk> - 2020-06-07 21:00 +0200
              Re: Zoom- best practice? Peter Ehlert <peter@sdi-baja.com> - 2020-06-07 21:20 +0200
            Re: Zoom- best practice? Seeds Notoneofmy <notoneofmyseeds@gmx.de> - 2020-06-07 21:10 +0200
            Re: Zoom- best practice? The Wanderer <wanderer@fastmail.fm> - 2020-06-07 22:00 +0200
              Re: Zoom- best practice? Nicolas George <george@nsup.org> - 2020-06-07 23:10 +0200
                Re: Zoom- best practice? Anastasios Lisgaras <tasosnumberten@yahoo.gr> - 2020-06-08 16:00 +0200
              Re: Zoom- best practice? The Wanderer <wanderer@fastmail.fm> - 2020-06-07 23:10 +0200
              Re: Zoom- best practice? "Russell L. Harris" <russell@rlharris.org> - 2020-06-07 23:10 +0200
                Re: Zoom- best practice? Tom Dial <tddial@comcast.net> - 2020-06-08 23:20 +0200
                  Re: Zoom- best practice? <tomas@tuxteam.de> - 2020-06-09 10:50 +0200
                    Re: Zoom- best practice? Nicolas George <george@nsup.org> - 2020-06-09 11:50 +0200
                      Re: Zoom- best practice? rhkramer@gmail.com - 2020-06-09 17:10 +0200
                        Re: Zoom- best practice? Alberto Sentieri <22t@tripolho.com> - 2020-06-09 20:00 +0200
                          Re: Zoom- best practice? Peter Ehlert <peter@sdi-baja.com> - 2020-06-09 20:30 +0200
                    Re: Zoom- best practice? The Wanderer <wanderer@fastmail.fm> - 2020-06-09 12:50 +0200
                      Re: Zoom- best practice? Nicolas George <george@nsup.org> - 2020-06-09 13:00 +0200
                        Re: Zoom- best practice? The Wanderer <wanderer@fastmail.fm> - 2020-06-09 13:10 +0200
                          Re: Zoom- best practice? Nicolas George <george@nsup.org> - 2020-06-10 15:30 +0200
                            Reply semantics, yet again (was Re: Zoom- best practice?) The Wanderer <wanderer@fastmail.fm> - 2020-06-10 16:00 +0200
                              Re: Reply semantics, yet again (was Re: Zoom- best practice?) Nicolas George <george@nsup.org> - 2020-06-11 17:20 +0200
                        Re: Zoom- best practice? Michael Stone <mstone@debian.org> - 2020-06-10 15:20 +0200
                          Re: Zoom- best practice? Nicolas George <george@nsup.org> - 2020-06-10 15:20 +0200
                            Re: Zoom- best practice? Michael Stone <mstone@debian.org> - 2020-06-10 15:30 +0200
                            Re: Zoom- best practice? Paul Johnson <baloo@ursamundi.org> - 2020-06-10 16:00 +0200
                      Re: Zoom- best practice? <tomas@tuxteam.de> - 2020-06-09 14:00 +0200
            Re: Zoom- best practice? "Russell L. Harris" <russell@rlharris.org> - 2020-06-07 22:00 +0200
              Re: Zoom- best practice? Dan Ritter <dsr@randomstring.org> - 2020-06-08 03:50 +0200
              Re: Zoom- best practice? David Wright <deblis@lionunicorn.co.uk> - 2020-06-08 03:50 +0200
          Re: Zoom- best practice? <tomas@tuxteam.de> - 2020-06-07 20:40 +0200
          Re: Zoom- best practice? rhkramer@gmail.com - 2020-06-07 21:00 +0200
    Re: Zoom- best practice? Greg Wooledge <wooledg@eeg.ccf.org> - 2020-06-05 19:10 +0200
      Re: Zoom- best practice? Seeds Notoneofmy <notoneofmyseeds@gmx.de> - 2020-06-07 20:10 +0200
    Re: Zoom- best practice? "der.hans" <deb-user@LuftHans.com> - 2020-06-05 19:10 +0200
      Re: Zoom- best practice? Peter Ehlert <peter@sdi-baja.com> - 2020-06-05 21:40 +0200
    Re: Zoom- best practice? john doe <johndoe65534@mail.com> - 2020-06-05 19:40 +0200
      Re: Zoom- best practice? Keith bainbridge <keithrbau@gmail.com> - 2020-06-07 07:20 +0200
        Re: Zoom- best practice? Peter Ehlert <peter@sdi-baja.com> - 2020-06-07 16:10 +0200
          Re: Zoom- best practice? Admin4 <admin4@dwaves.de> - 2020-06-07 20:10 +0200
            Re: Zoom- best practice? Jude DaShiell <jdashiel@panix.com> - 2020-06-07 20:30 +0200
    Re: Zoom- best practice? Charles Curley <charlescurley@charlescurley.com> - 2020-06-05 19:50 +0200
    Re: Zoom- best practice? Brian <ad44@cityscape.co.uk> - 2020-06-05 21:50 +0200
      Re: Zoom- best practice? Dominik George <nik@naturalnet.de> - 2020-06-05 23:10 +0200
      Re: Zoom- best practice? Tom Dial <tddial@comcast.net> - 2020-06-06 03:30 +0200
    Re: Zoom- best practice? Linux-Fan <Ma_Sys.ma@web.de> - 2020-06-06 00:20 +0200
      Re: Zoom- best practice? <tomas@tuxteam.de> - 2020-06-06 10:40 +0200
      Re: Zoom- best practice? Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2020-06-06 13:20 +0200
        Re: Zoom- best practice? <tomas@tuxteam.de> - 2020-06-06 17:50 +0200
          Re: Zoom- best practice? Paul Johnson <baloo@ursamundi.org> - 2020-06-06 18:00 +0200
    Re: Zoom- best practice? Ryan Nowakowski <tubaman@fattuba.com> - 2020-06-12 00:30 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#223203

[Multipart message — attachments visible in raw view] — view raw

On 2020-06-07 at 15:30, Russell L. Harris wrote:

> On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote:
> 
>> tomas@tuxteam.de (12020-06-07):
>> 
>>> Yes, the server is free software. As is Jitsi's. So you can get
>>> the source, build yourself or download pre-built thingies.
>> 
>> Do you have evidence of somebody other than the authors themselves 
>> having managed to build it?
> 
> A few months ago, I installed a Jitsi server from Debian packages 
> downloaded from the Jitsi web site.  The installation was on an old 
> machine (Intel or AMD64) running Debian (9 or 10).  I followed the 
> instructions in an installation video produced by Jitsi; the 
> installation was without difficulty.  I and a friend then 
> video-conferenced over the system; everything worked "as
> advertised".

Yeah, but that's not building Jitsi; that's installing a prebuilt Jitsi,
as shipped in those packages.

Presumably, as those packages are for download from the authors'
Website, the authors are the ones who built them. Thus, this doesn't
demonstrate that anyone other than the authors have been able to build
Jitsi.

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

[toc] | [prev] | [next] | [standalone]

#223212

[Multipart message — attachments visible in raw view] — view raw

Russell L. Harris (12020-06-07):
> So? It is an open-source alternative to Zoom, and it works.  Of
> course, if you are worried that the builders put in something
> malicious or dangerous which is not in the open source repository,
> then you can turn to Zoom, or build your own, or do without...
> 
> Though objectivity is prudent, we ought be promoting alternatives to
> Zoom, rather than torpedoing them.

Open Source is not enough.

I did not think it would be necessary to explain why Libre Software is
important here. It is not just a matter of possible malicious in the
code, it is a matter of being able to change it to suit our needs, to
fix it if there are bugs, to include parts into other projects. If all
of this is not possible, it is a dead-end project, a waste of energy,
only marginally better than closed-source surveillanceware.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#223243

On 6/8/20 12:06 AM, Nicolas George wrote:
> Open Source is not enough.
> 
> I did not think it would be necessary to explain why Libre Software is
> important here. It is not just a matter of possible malicious in the
> code, it is a matter of being able to change it to suit our needs, to
> fix it if there are bugs, to include parts into other projects. If all
> of this is not possible, it is a dead-end project, a waste of energy,
> only marginally better than closed-source surveillanceware.
> 
> Regards,

An interesting point of view that I agree with.
It is a very delicate and important piece, which some consider a detail 
or do not pay attention to. But personally I agree with you, it matters.

But, do you mention this because of the jitsi license that is *Apache 
License 2.0 ?
https://github.com/jitsi/jitsi-videobridge

-- 
Kind regards,
Anastasios Lisgaras

[toc] | [prev] | [next] | [standalone]

#223213

[Multipart message — attachments visible in raw view] — view raw

On 2020-06-07 at 16:14, Russell L. Harris wrote:

> On Sun, Jun 07, 2020 at 03:56:17PM -0400, The Wanderer wrote:
> 
>> Yeah, but that's not building Jitsi; that's installing a prebuilt
>> Jitsi, as shipped in those packages.
>> 
>> Presumably, as those packages are for download from the authors'
>> Website, the authors are the ones who built them. Thus, this
>> doesn't demonstrate that anyone other than the authors have been
>> able to build Jitsi.
> 
> So? It is an open-source alternative to Zoom, and it works.

The post to which you were responding had just asked the question

>>> Do you have evidence of somebody other than the authors
>>> themselves having managed to build it?

and, because your post started immediately after that, I inferred that
it was intended to be a response to that question.

As far as I can see, your post does not seem to provide any such
evidence. I was pointing that out.

If I parse you correctly, you now seem to be asserting that this is not
an appropriate / relevant question. However, your previous post did not
seem to make clear that you were doing so.

> Of course, if you are worried that the builders put in something
> malicious or dangerous which is not in the open source repository,
> then you can turn to Zoom, or build your own, or do without...
> 
> Though objectivity is prudent, we ought be promoting alternatives to
> Zoom, rather than torpedoing them.

While this is true, and would be on-topic for the thread if the OP
hadn't already said that anything but Zoom is a nonstarter because Zoom
is what the people he needs to speak with are already using and they
aren't going to change, it's not relevant to the question to which your
comments were posted as a reply.

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

[toc] | [prev] | [next] | [standalone]

#223214

On Sun, Jun 07, 2020 at 03:56:17PM -0400, The Wanderer wrote:
>Yeah, but that's not building Jitsi; that's installing a prebuilt Jitsi,
>as shipped in those packages.
>
>Presumably, as those packages are for download from the authors'
>Website, the authors are the ones who built them. Thus, this doesn't
>demonstrate that anyone other than the authors have been able to build
>Jitsi.

So? It is an open-source alternative to Zoom, and it works.  Of
course, if you are worried that the builders put in something
malicious or dangerous which is not in the open source repository,
then you can turn to Zoom, or build your own, or do without...

Though objectivity is prudent, we ought be promoting alternatives to
Zoom, rather than torpedoing them.

RLH

[toc] | [prev] | [next] | [standalone]

#223262

On 6/7/20 14:14, Russell L. Harris wrote:
> On Sun, Jun 07, 2020 at 03:56:17PM -0400, The Wanderer wrote:
>> Yeah, but that's not building Jitsi; that's installing a prebuilt Jitsi,
>> as shipped in those packages.
>>
>> Presumably, as those packages are for download from the authors'
>> Website, the authors are the ones who built them. Thus, this doesn't
>> demonstrate that anyone other than the authors have been able to build
>> Jitsi.
> 
> So? It is an open-source alternative to Zoom, and it works.  Of
> course, if you are worried that the builders put in something
> malicious or dangerous which is not in the open source repository,
> then you can turn to Zoom, or build your own, or do without...
> 
> Though objectivity is prudent, we ought be promoting alternatives to
> Zoom, rather than torpedoing them.

If you cannot build an executable from source, you do not know whether
the binary you downloaded represents the source faithfully. Even if you
have the source, it would take great effort and use of some fairly
esoteric tools to verify that the product is what it says it is, and
does what it says it does (and no more).

As I understand, that is a primary goal of Debian's fairly extensive
effort to ensure that builds for its packages are reproducible.


Building from source is not the only requisite for such assurance,
however. Ken Thompson's ACM Turing Award lecture, "Reflections on
Trusting Trust" [1] is an interesting take on this aspect of security.


Free (or even open source) is a good software characteristic, but it is
not the only one that counts, or even the most important one. Sometimes,
as it may be with Zoom, a closed source commercial product is better
than free alternatives. Even where that is not so such a product may, as
Zoom is, be so much more widely used that it is much more useful as a
general matter.

Regards
Tom Dial

[1] https://dl.acm.org/doi/10.1145/358198.358210

> 
> RLH

[toc] | [prev] | [next] | [standalone]

#223276

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 08, 2020 at 02:59:13PM -0600, Tom Dial wrote:
> 
> 
> On 6/7/20 14:14, Russell L. Harris wrote:
> > On Sun, Jun 07, 2020 at 03:56:17PM -0400, The Wanderer wrote:
> >> Yeah, but that's not building Jitsi; that's installing a prebuilt Jitsi,
> >> as shipped in those packages.
> >>
> >> Presumably, as those packages are for download from the authors'
> >> Website, the authors are the ones who built them. Thus, this doesn't
> >> demonstrate that anyone other than the authors have been able to build
> >> Jitsi.
> > 
> > So? It is an open-source alternative to Zoom, and it works.  Of
> > course, if you are worried that the builders put in something
> > malicious or dangerous which is not in the open source repository,
> > then you can turn to Zoom, or build your own, or do without...
> > 
> > Though objectivity is prudent, we ought be promoting alternatives to
> > Zoom, rather than torpedoing them.
> 
> If you cannot build an executable from source, you do not know whether
> the binary you downloaded represents the source faithfully.

Can we stop that already? Nobody proved you can't build Jitsi or
BBB from source. Everyone here is just too friggin' lazy to even
try.

Can we give 'em the benefit of the doubt until someone really makes
his hands ditry on that?

That's how fake news spread, btw.

I think it's somewhat disgusting. Folks, put up... or shut up now.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#223277

[Multipart message — attachments visible in raw view] — view raw

tomas@tuxteam.de (12020-06-09):
> Can we stop that already? Nobody proved you can't build Jitsi or
> BBB from source. Everyone here is just too friggin' lazy to even
> try.
> 
> Can we give 'em the benefit of the doubt until someone really makes
> his hands ditry on that?

You can be naïve and give them the benefit of the doubt. But I will not.
Jitsi is a big project, it claims the reputation benefits of being Libre
Software: the onus of proof is on it.

I will state and repeat: until we see actual reliable proof, claiming
that Jitsi is Libre Software is wrong.

> That's how fake news spread, btw.
> 
> I think it's somewhat disgusting. Folks, put up... or shut up now.

Your attempt at irrational shaming is dishonest.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#223284

On Tuesday, June 09, 2020 05:45:24 AM Nicolas George wrote:
> tomas@tuxteam.de (12020-06-09):
> > Can we stop that already? Nobody proved you can't build Jitsi or
> > BBB from source. Everyone here is just too friggin' lazy to even
> > try.
> > 
> > Can we give 'em the benefit of the doubt until someone really makes
> > his hands ditry on that?
> 
> You can be naïve and give them the benefit of the doubt. But I will not.


> Jitsi is a big project, it claims the reputation benefits of being Libre
> Software: the onus of proof is on it.

+1

If a project is new, I'm willing to give a project the benefit of the doubt on 
the assumption that it is a statement of intent, and, as they recognize 
shortcomings, they will fix them.  


> I will state and repeat: until we see actual reliable proof, claiming
> that Jitsi is Libre Software is wrong.
> 
> > That's how fake news spread, btw.
> > 
> > I think it's somewhat disgusting. Folks, put up... or shut up now.
> 
> Your attempt at irrational shaming is dishonest.
> 
> Regards,

[toc] | [prev] | [next] | [standalone]

#223286

This is a long thread. I did not read it all. Did anyone suggest 
http://meet.google.com?

[toc] | [prev] | [next] | [standalone]

#223290

[Multipart message — attachments visible in raw view] — view raw

Original post: family is using Zoom.
No alternative for me to participate... Zoom or nothing.
Thanks for the suggestion.
Peter Ehlert
On June 9, 2020 10:56:10 AM Alberto Sentieri <22t@tripolho.com> wrote:

> This is a long thread. I did not read it all. Did anyone suggest
> http://meet.google.com?

[toc] | [prev] | [next] | [standalone]

#223279

[Multipart message — attachments visible in raw view] — view raw

(Please stop CCing me on replies - especially to messages which I did
not actually send - unless you're specifically trying to draw my
attention to a particular message and think I may not notice it without
the CC. Not only am I subscribed, I am in fact reading this thread on a
multiple-times-a-day basis, as my multiple replies to it to date may
have indicated.)

On 2020-06-09 at 04:42, tomas@tuxteam.de wrote:

> On Mon, Jun 08, 2020 at 02:59:13PM -0600, Tom Dial wrote:

>> If you cannot build an executable from source, you do not know
>> whether the binary you downloaded represents the source
>> faithfully.
> 
> Can we stop that already? Nobody proved you can't build Jitsi or BBB
> from source. Everyone here is just too friggin' lazy to even try.
> 
> Can we give 'em the benefit of the doubt until someone really makes 
> his hands ditry on that?

FWIW, I have tried, at least in part.

For the individual broken-out projects (which may or may not be rolled
up into the larger "master" project, I can't easily tell), I succeeded
with one, and failed with another, but suspect that I could succeed with
the latter with more effort.

For the apparent "master" project, I admit that I didn't bother to try,
because of the exact "too many prebuilt apparent-dependency objects with
no apparent way provided to rebuild them" issue; unless we can rebuild
those objects, not only can we not be sure we have the source for them,
we can't be sure that building with a different version of that object
will even work.

Even a successful build from a repository like that would not
demonstrate that you can actually completely rebuild the project from
scratch; you'd have to actually track down the source for all of those
individual prebuilt objects, rebuild each one, and pull the result in to
the build in a way which will get picked up, and that's more effort than
I'm willing to put in for the sake of a mailing-list discussion like
this one.

I don't fault the developers too much for providing a version of the
project tree with prebuilt dependencies like that; it's a useful
convenience for those who just want to get it to work and for whom
farting around with trying to find the right dependencies and get them
into place would be too much of a hassle. But for (as far as I can tell)
providing the tree in *only* that form, and not providing (as far as
I've found) *any* documentation on what these prebuilt objects are and
why they're needed and how to get them separately and build them and so
forth, there I do fault them, and consider that a ding against proper
Free status.

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

[toc] | [prev] | [next] | [standalone]

#223280

[Multipart message — attachments visible in raw view] — view raw

The Wanderer (12020-06-09):
> (Please stop CCing me on replies - especially to messages which I did
> not actually send - unless you're specifically trying to draw my
> attention to a particular message and think I may not notice it without
> the CC. Not only am I subscribed, I am in fact reading this thread on a
> multiple-times-a-day basis, as my multiple replies to it to date may
> have indicated.)

Instead of writing this periodically, you could include:
Reply-To: debian-user@lists.debian.org
in your headers just like I did. Properly configured mailing-list
software does it by default for subscribed users, but Debian is an
exception. It fixes the issue of annoying ccs once and for all.

> FWIW, I have tried, at least in part.
> 
> For the individual broken-out projects (which may or may not be rolled
> up into the larger "master" project, I can't easily tell), I succeeded
> with one, and failed with another, but suspect that I could succeed with
> the latter with more effort.
> 
> For the apparent "master" project, I admit that I didn't bother to try,
> because of the exact "too many prebuilt apparent-dependency objects with
> no apparent way provided to rebuild them" issue; unless we can rebuild
> those objects, not only can we not be sure we have the source for them,
> we can't be sure that building with a different version of that object
> will even work.
> 
> Even a successful build from a repository like that would not
> demonstrate that you can actually completely rebuild the project from
> scratch; you'd have to actually track down the source for all of those
> individual prebuilt objects, rebuild each one, and pull the result in to
> the build in a way which will get picked up, and that's more effort than
> I'm willing to put in for the sake of a mailing-list discussion like
> this one.

Thank you for these clarifications.

> I don't fault the developers too much for providing a version of the
> project tree with prebuilt dependencies like that; it's a useful
> convenience for those who just want to get it to work and for whom
> farting around with trying to find the right dependencies and get them
> into place would be too much of a hassle. But for (as far as I can tell)
> providing the tree in *only* that form, and not providing (as far as
> I've found) *any* documentation on what these prebuilt objects are and
> why they're needed and how to get them separately and build them and so
> forth, there I do fault them, and consider that a ding against proper
> Free status.

I state it that way: the knowledge of how to obtain and build these
objects is part of the source code of the project, just as much as a
makefile or configure script. Unfortunately, that bit of source code
only resides in the head of the developers, it is not distributed.

Consider a minified javascript program with a GPL license header slapped
on top of it: should we consider it Libre Software? Of course not. The
same happens here: out of negligence probably, the authors keep part of
the source code for themselves. It is not Libre Software.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#223281

[Multipart message — attachments visible in raw view] — view raw

On 2020-06-09 at 06:51, Nicolas George wrote:

> The Wanderer (12020-06-09):
> 
>> (Please stop CCing me on replies - especially to messages which I
>> did not actually send - unless you're specifically trying to draw
>> my attention to a particular message and think I may not notice it
>> without the CC. Not only am I subscribed, I am in fact reading this
>> thread on a multiple-times-a-day basis, as my multiple replies to
>> it to date may have indicated.)
> 
> Instead of writing this periodically, you could include:
> Reply-To: debian-user@lists.debian.org
> in your headers just like I did.

Having to add that by hand to every single reply I make would be much
more of a hassle than taking the time to request this explicitly on the
relatively few occasions when people send such CCs with enough frequency
for it to be a bother to me.

> Properly configured mailing-list software does it by default for
> subscribed users, but Debian is an exception. It fixes the issue of
> annoying ccs once and for all.

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.

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.

>> FWIW, I have tried, at least in part.
>> 
>> For the individual broken-out projects (which may or may not be
>> rolled up into the larger "master" project, I can't easily tell), I
>> succeeded with one, and failed with another, but suspect that I
>> could succeed with the latter with more effort.
>> 
>> For the apparent "master" project, I admit that I didn't bother to
>> try, because of the exact "too many prebuilt apparent-dependency
>> objects with no apparent way provided to rebuild them" issue;
>> unless we can rebuild those objects, not only can we not be sure we
>> have the source for them, we can't be sure that building with a
>> different version of that object will even work.
>> 
>> Even a successful build from a repository like that would not 
>> demonstrate that you can actually completely rebuild the project
>> from scratch; you'd have to actually track down the source for all
>> of those individual prebuilt objects, rebuild each one, and pull
>> the result in to the build in a way which will get picked up, and
>> that's more effort than I'm willing to put in for the sake of a
>> mailing-list discussion like this one.
> 
> Thank you for these clarifications.
> 
>> I don't fault the developers too much for providing a version of
>> the project tree with prebuilt dependencies like that; it's a
>> useful convenience for those who just want to get it to work and
>> for whom farting around with trying to find the right dependencies
>> and get them into place would be too much of a hassle. But for (as
>> far as I can tell) providing the tree in *only* that form, and not
>> providing (as far as I've found) *any* documentation on what these
>> prebuilt objects are and why they're needed and how to get them
>> separately and build them and so forth, there I do fault them, and
>> consider that a ding against proper Free status.
> 
> I state it that way: the knowledge of how to obtain and build these 
> objects is part of the source code of the project, just as much as a 
> makefile or configure script. Unfortunately, that bit of source code 
> only resides in the head of the developers, it is not distributed.
> 
> Consider a minified javascript program with a GPL license header
> slapped on top of it: should we consider it Libre Software? Of course
> not. The same happens here: out of negligence probably, the authors
> keep part of the source code for themselves. It is not Libre
> Software.

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

I just don't care to bother with doing that myself at present. Which, to
an extent, turns things back to Tomas' point.

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

[toc] | [prev] | [next] | [standalone]

#223306

[Multipart message — attachments visible in raw view] — view raw

The Wanderer (12020-06-09):
> 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-user@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.

> 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. I personally reject
any solution with that requirement, since there are solutions without.

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

> I just don't care to bother with doing that myself at present. Which, to
> an extent, turns things back to Tomas' point.

Tomas's point is "give the benefit of the doubt", but at this point
there is not much doubt left.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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-user@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

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

[ 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

[toc] | [prev] | [next] | [standalone]

#223302

On Tue, Jun 09, 2020 at 12:51:00PM +0200, Nicolas George wrote:
>Instead of writing this periodically, you could include:
>Reply-To: debian-user@lists.debian.org
>in your headers just like I did. Properly configured mailing-list
>software does it by default for subscribed users, but Debian is an
>exception. It fixes the issue of annoying ccs once and for all.

Properly configured mailing list software does no such thing, since it's 
a misuse of the reply-to header. A better solution is to use a better 
program to read mail.

[toc] | [prev] | [next] | [standalone]

#223303

[Multipart message — attachments visible in raw view] — view raw

Michael Stone (12020-06-10):
> Properly configured mailing list software does no such thing, since it's a
> misuse of the reply-to header.

A misuse that works, compared to non-misuses that regularly bring back
"don't cc me" subthreads. At some points, the religion of "properly"
using headers need to cede to the pragmatism.

You need to realize that a solution that requires the user to use a
different key/command if they are replying to a list than if they are
not is inferior to a solution that works with always the same key.

>				 A better solution is to use a better program
> to read mail.

You mean I should use Mutt, like you?

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#223305

On Wed, Jun 10, 2020 at 03:17:34PM +0200, Nicolas George wrote:
>Michael Stone (12020-06-10):
>> Properly configured mailing list software does no such thing, since it's a
>> misuse of the reply-to header.
>
>A misuse that works, 

Except for the things that it breaks, and the cases for which it doesn't 
work. So, no.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web