Re: Setup sound for zoom conferencing
On 7/18/20 4:52 PM, Bob Weber wrote: On 7/18/20 6:46 PM, Gary L. Roach wrote: Installed Alsa, asound OS Debian 10 Hi all, I have standard alsa sound installed in my system and it works fine for most things. Recently I started using Zoom, have installed a Logitech C920 webcam with stereo microphones and a Sennheiser HD4.50BTNC headphones with stereo microphones. I now have a conflict between the mic inputs from the two devices. The bluetooth connections is through a dongle plugged into one of my usb ports. The Logitech also plugs into one of my usb ports. I want to use the mics from the HD4.50 and shut down the mics on the Logitech. I also want to shut down the speaker bar on my monitor and just use the headphones. How do I do this. Another want is to have a graphic equalizer in the chain. I can't seem to find any software that would do this. All help will be sincerely appreciated. Gary R. Have you tried pulseaudio? If the devices are visible to pulse then pavucontrol can connect and control volumes of all the devices. pulseaudio even has many modules like a loop device to extend pulseaudio. -- *...Bob* Yes I have pulseaudio, pulseaudio volume and any other associated package that I could find. The problem seems to be that pulseaudio does not recognize my headset microphones. They don't show up in the device list. I also find it a bit confusing when the volume panel lists front and back microphones when there is no back microphone. The front one seems to be the mic's on my webcam. The back one ??? Gary R.
Setup sound for zoom conferencing
Installed Alsa, asound OS Debian 10 Hi all, I have standard alsa sound installed in my system and it works fine for most things. Recently I started using Zoom, have installed a Logitech C920 webcam with stereo microphones and a Sennheiser HD4.50BTNC headphones with stereo microphones. I now have a conflict between the mic inputs from the two devices. The bluetooth connections is through a dongle plugged into one of my usb ports. The Logitech also plugs into one of my usb ports. I want to use the mics from the HD4.50 and shut down the mics on the Logitech. I also want to shut down the speaker bar on my monitor and just use the headphones. How do I do this. Another want is to have a graphic equalizer in the chain. I can't seem to find any software that would do this. All help will be sincerely appreciated. Gary R.
Resolved (at least the sound) Re: Zoom client for Linux (was: Re: Advice on encrypted filesystem)
On Thursday, June 25, 2020 10:14:50 AM rhkra...@gmail.com wrote: > Can you give me any clues about how you told it which audio device to use > (and which you told it to use)? Ahh, I found the settings screen and switched the audio (to "Built In Analog Audio Stereo") and tested it -- it works. (I believe there is a test meeting somewhere, I want to try connecting to that to make sure things are working, and then I want to change my screen name -- I'm guessing I'll figure those out.
Zoom client for Linux (was: Re: Advice on encrypted filesystem)
On Thursday, June 25, 2020 09:25:06 AM David wrote: > Hi, are you aware that Zoom has available a Linux-compatible > desktop client application that runs without a browser? Thanks, yes, that is one of the ways I tried to join the zoom meeting on my Jessie system -- the client says it requires / works with Debian 8.0 (i.e., Jessie) but I might also try it on Buster. I do have a followup question after the aside. (aside: long story slightly shortened> I have a zoom client on my Wheezy system, some 3.nn version, but the meeting I tried to join said I needed version 5.nn, which apparently cannot be installed on Wheezy. I tried joining the meeting with both the Linux client and Firefox, both gave me video but neither gave me sound. At some point I'll try Chromium (I think zoom has a test meeting that I can join to try out) (/aside: long story slightly shortened> > It works on Buster, apart from needing to be told which audio > device to use every time it is run. Can you give me any clues about how you told it which audio device to use (and which you told it to use)? > Available here: > https://zoom.us/download#client_4meeting
Re: Zoom- best practice?
On Fri, Jun 05, 2020 at 09:28:21AM -0700, Peter Ehlert wrote: > Family is using Zoom, International. > They will use Zoom, and I need to participate. > > I use Debian Mate Stable, and Firefox ESR > > I am concerned about security, duh! > Looking for ideas. > > my current thoughts, in order of preference: > > 2. Sandbox? (but how can I do that?) You might consider installing zoom as a snap package[1] instead of a deb. Snaps provide some confinement that, in theory, provide some extra level of security(harder for zoom to spread files all over your system, etc) Alternatively, install the zoom deb package in a chroot[2]. I like to use schroot to help with this kind of thing. Then create a separate dedicated user just for running zoom. That will help limit zoom's access to your normal user's data. [1] https://snapcraft.io/install/zoom-client/debian [2] https://wiki.debian.org/chroot
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 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?)
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
Re: Zoom- best practice?
On Wed, Jun 10, 2020 at 8:17 AM 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, 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? > Or literally any modern mail reader, all of which implement "reply to list". It's not like the mailing list isn't publishing list-id headers.
Re: Zoom- best practice?
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-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. > 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 signature.asc Description: PGP signature
Re: Zoom- best practice?
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.
Re: Zoom- best practice?
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 signature.asc Description: PGP signature
Re: Zoom- best practice?
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.
Re: Zoom- best practice?
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 <2...@tripolho.com> wrote: This is a long thread. I did not read it all. Did anyone suggest http://meet.google.com?
Re: Zoom- best practice?
This is a long thread. I did not read it all. Did anyone suggest http://meet.google.com?
Re: Zoom- best practice?
On Tuesday, June 09, 2020 05:45:24 AM Nicolas George wrote: > to...@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,
Re: Zoom- best practice?
On Tue, Jun 09, 2020 at 06:41:33AM -0400, The Wanderer wrote: > (Please stop CCing me on replies [...] Sorry. [...] > FWIW, I have tried, at least in part. Thanks for taking the time to do, and thanks for reporting back. [...] > Even a successful build from a repository like that would not > demonstrate that you can actually completely rebuild the project from > scratch [...] Yes, this is a well-known problem with many facets. ISTR that there was a Lisp which only could build itself: the whole buildery (which, this being Lisp included everything, compiler, assembler and all) was written in Lisp, and took advantage of newer and newer features. A full bootstrap involved unearthing "old versions" and following the historical evolution of that thing. Some "ecosystems", like Java, tend to build up a huge network of dependencies on "well-known" components -- something I used to call it the "Java Disease". Until Javascript came with npm, or PHP with composer. It can get worse. Building something significant, like Jitsi, lands you in this hell, and to survive, you end up ingesting those dependencies (that's what is called "vendoring" -- imo the Euphemism of the Decennium). On the other end there are heroes, like the Guix folks [1], or the reproducible build folks [2] working relentlessly on disentangling those things. Debian packaging belongs into that class of heroism. So from my POV there is a lot to critizice there, and a lot to fix -- but "this is not free software just because I'm too lazy to check thoroughly", as some have basically said here is simply unfair -- and counterproductive. Cheers [1] https://guix.gnu.org/ [2] https://reproducible-builds.org/ -- tomás signature.asc Description: Digital signature
Re: Zoom- best practice?
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
Re: Zoom- best practice?
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 signature.asc Description: PGP signature
Re: Zoom- best practice?
(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, to...@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 signature.asc Description: OpenPGP digital signature
Re: Zoom- best practice?
to...@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 signature.asc Description: PGP signature
Re: Zoom- best practice?
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 signature.asc Description: Digital signature
Re: Zoom- best practice?
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
Re: Zoom- best practice?
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
Re: Zoom- best practice?
David Wright wrote: > On Sun 07 Jun 2020 at 19:30:19 (+), Russell L. Harris wrote: > > On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote: > > > to...@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. > > What do you mean by Jitsi server from Debian packages? I get: > >"You have searched for packages that names contain jitsi in all >suites, all sections, and all architectures. > >"Sorry, your search gave no results" The Jitsi team is currently making a .deb repo available, and updating every 2-3 days. I presume that when it's stable, they'll offer it to Debian proper -- it's all under Apache License 2.0, no problems including it in main. deb https://download.jitsi.org stable/ -dsr-
Re: Zoom- best practice?
On Sun 07 Jun 2020 at 19:30:19 (+), Russell L. Harris wrote: > On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote: > > to...@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. What do you mean by Jitsi server from Debian packages? I get: "You have searched for packages that names contain jitsi in all suites, all sections, and all architectures. "Sorry, your search gave no results" Cheers, David.
Re: Zoom- best practice?
On Sun, Jun 07, 2020 at 11:17:39PM +0100, Brian wrote: > On Sun 07 Jun 2020 at 22:24:56 +0200, to...@tuxteam.de wrote: > > > On Sun, Jun 07, 2020 at 09:07:59PM +0100, Brian wrote: > > > > [...] > > > > > Nicolas George states the obvious. All modern VoIP involves immense > > > resources to deliver to users. > > > > A bit handwawy at that point: do you mean it's a complex programming > > task or it needs network resources (bandwidth, low latency)? > > Both, but mainly the latter. And lots of organisation and money. As for the latter: these folks [1] (sorry, in German), Freifunk München tinker around with mesh networking to offer free WiFi in the city of Munich (there are similar groups in other cities) and are experimenting with a distributed Jitsi videobridge which reportedly has supported up to 200 sessions. You can view current stats here [2]. Defetism is unsexy ;-) Cheers [1] https://ffmuc.net/ [2] https://stats.ffmuc.net/d/U6sKqPuZz/meet-stats?orgId=1&refresh=1m -- t signature.asc Description: Digital signature
Re: Zoom- best practice?
On Sun 07 Jun 2020 at 22:24:56 +0200, to...@tuxteam.de wrote: > On Sun, Jun 07, 2020 at 09:07:59PM +0100, Brian wrote: > > [...] > > > Nicolas George states the obvious. All modern VoIP involves immense > > resources to deliver to users. > > A bit handwawy at that point: do you mean it's a complex programming > task or it needs network resources (bandwidth, low latency)? Both, but mainly the latter. And lots of organisation and money. > > Resources cost money. Linux Central is out of funds. > > Who is Linux Central? The entity that funds VoIP facilities like Zoom and WhatsApp. It doesn't exist and never will. Therefore, there will never be any Libre Software competitors to the commercial videoconferencing offerings. -- Brian.
Re: Zoom- best practice?
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 signature.asc Description: OpenPGP digital signature
Re: Zoom- best practice?
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 signature.asc Description: PGP signature
Re: Zoom- best practice?
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
Re: Zoom- best practice?
On Sun, Jun 07, 2020 at 09:07:59PM +0100, Brian wrote: [...] > Nicolas George states the obvious. All modern VoIP involves immense > resources to deliver to users. A bit handwawy at that point: do you mean it's a complex programming task or it needs network resources (bandwidth, low latency)? > Resources cost money. Linux Central is out of funds. Who is Linux Central? > Videoconferencing on a mass scale is beyond the capabilities of what > is available in Debian. Debian is a distribution. Very little (relative to the whole packaged content) is written explicitly for Debian/by Debian developers. You don't really make sense, sorry. Cheers -- tomás signature.asc Description: Digital signature
Re: Zoom- best practice?
On Sun 07 Jun 2020 at 21:19:08 +0200, to...@tuxteam.de wrote: > On Sun, Jun 07, 2020 at 08:57:54PM +0200, Nicolas George wrote: > > to...@tuxteam.de (12020-06-07): > > > No. But I haven't tried, so... > > > > Well, me neither. But if I have not tried personally, I know people who > > have tried and failed. > > > > If only the authors can build a software, it cannot be considered Libre > > Software, since part of the source code is missing. Open Source at best. > > > > We have to acknowledge: there are no Libre Software solutions for > > videoconferencing. > > You may acknowledge what you want. I don't. As long as I don't try > to make my fingers dirty, I'll refrain from issuing any judgement. > > You keep your belief. I stay agnostic, at this stage. Nicolas George states the obvious. All modern VoIP involves immense resources to deliver to users. Resources cost money. Linux Central is out of funds. Videoconferencing on a mass scale is beyond the capabilities of what is available in Debian. -- Brian
Re: Zoom- best practice?
On 2020-06-07 at 15:30, Russell L. Harris wrote: > On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote: > >> to...@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 signature.asc Description: OpenPGP digital signature
Re: Zoom- best practice?
On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote: to...@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". I am out in central Texas, with a low-bandwidth Internet connection provided by a microwave link.
Re: Zoom- best practice?
On 2020-06-07 at 15:34, Nicolas George wrote: > Darac Marjal (12020-06-07): > >> That's a rather ironic thing to say on a Debian mailing list :) > > To the best of my knowledge, Debian is not the author of most > packages, and yet build them from source themselves: that proves the > packages are actually Libre Software. Again to the best of my > knowledge, for most packages, any user can rebuild them from source > and it works, Debian makes a lot of effort for that. > > Can you say the same for these repositories? FWIW, in response to this thread I just went on an attempt to build Jitsi myself. As far as I can tell at a skim of their Website and GitHub pages, this seems to consist of two components, which are kept in separate repositories and built / packaged separately: jitsi-meet / jitsi-meet-web, the Web-interface UI for accessing the system, and jitsi-videobridge, the actual videoconferencing backend (or something like that). I was able to successfully build a jitsi-videobridge Debian package from current GitHub master, via dpkg-buildpackage, with only a little difficulty and a few false starts. I failed utterly in building a jitsi-meet(-web) Debian package from current GitHub master by the same method; at least one file it relies upon early in the build (css/all.css) is not included in the repository, the tools it appears to expect to use to build that file do not appear to be included or declared as build dependencies, and I don't see any build documentation at all aside from debian/rules and the (generated?) Makefile. I could probably bang my head against this wall for a while longer and get it working, but I don't care to install more things onto my machine in stabs in the dark for something I don't actually currently plan to use. So your point about this at least not being straightforward to build seems proven, at least to a first-effort approximation. -- 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
Re: Zoom- best practice?
Darac Marjal (12020-06-07): > That's a rather ironic thing to say on a Debian mailing list :) To the best of my knowledge, Debian is not the author of most packages, and yet build them from source themselves: that proves the packages are actually Libre Software. Again to the best of my knowledge, for most packages, any user can rebuild them from source and it works, Debian makes a lot of effort for that. Can you say the same for these repositories? Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Zoom- best practice?
On 07/06/2020 20:21, Nicolas George wrote: > Seeds Notoneofmy (12020-06-07): >> Having said all that, the instructions to get BBB going seems solid. >> Perhaps someone here with a bit of knowhow will do this and then put a >> guide here? That would be very, very nice: >> >> Here's my contribution: >> >> https://docs.bigbluebutton.org/2.2/install.html > Installing from a binary repository: yes, that works. But that's not > Libre Software. That's a rather ironic thing to say on a Debian mailing list :) signature.asc Description: OpenPGP digital signature
Re: Zoom- best practice?
Seeds Notoneofmy (12020-06-07): > Having said all that, the instructions to get BBB going seems solid. > Perhaps someone here with a bit of knowhow will do this and then put a > guide here? That would be very, very nice: > > Here's my contribution: > > https://docs.bigbluebutton.org/2.2/install.html Installing from a binary repository: yes, that works. But that's not Libre Software. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Zoom- best practice?
On Sun, Jun 07, 2020 at 08:57:54PM +0200, Nicolas George wrote: > to...@tuxteam.de (12020-06-07): > > No. But I haven't tried, so... > > Well, me neither. But if I have not tried personally, I know people who > have tried and failed. > > If only the authors can build a software, it cannot be considered Libre > Software, since part of the source code is missing. Open Source at best. > > We have to acknowledge: there are no Libre Software solutions for > videoconferencing. You may acknowledge what you want. I don't. As long as I don't try to make my fingers dirty, I'll refrain from issuing any judgement. You keep your belief. I stay agnostic, at this stage. Cheers -- t signature.asc Description: Digital signature
Re: Zoom- best practice?
On 6/7/20 11:53 AM, Brian wrote: On Sun 07 Jun 2020 at 20:37:55 +0200, Nicolas George wrote: to...@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? The OP says: > Family is using Zoom, International. > They will use Zoom, and I need to participate. If he wishes to participate he uses Zoom. Correct. The family has meetings with Zoom, I wish to attend... so I will use Zoom. That is the bottom line. sorry I was not super clear about that point at the onset. I really do appreciate the suggestions for alternate solutions... I may use that info for different groups. There isn't any interworking between it and other similar programs. Discussion about Zoom can go on endlessly. It doesn't alter the technical fact.
Re: Zoom- best practice?
On 6/7/20 8:57 PM, Nicolas George wrote: We have to acknowledge: there are no Libre Software solutions for videoconferencing. Having said all that, the instructions to get BBB going seems solid. Perhaps someone here with a bit of knowhow will do this and then put a guide here? That would be very, very nice: Here's my contribution: https://docs.bigbluebutton.org/2.2/install.html
Re: Zoom- best practice?
On 6/7/20 8:57 PM, Nicolas George wrote: We have to acknowledge: there are no Libre Software solutions for videoconferencing. Well, that's about wrap this thread up. Thanks. And I'm glad I did not proceed with the BBB promise. They've been around since 2007, but we cannot say of them, an alternative to Zoom, skype, etc. So, what is it; putting out stuff that only they could really use. Now! that's what I call a project. If I were a developer, here's my system for putting stuff online develop my code put it on github asking for contributors, not advertising it as a solution for any problem(s), or for anyone to use introduce it in forums like these, asking for testers and when all that is done, build a website and then promise that this will solve XYZ computing problem/need(s) to dream up an idea, throw code together and advertise the claim to have solved a problem when only you and your cat can use it is, well, 'false advertising.' :)
Re: Zoom- best practice?
On 6/7/20 8:37 PM, Nicolas George wrote: Do you have evidence of somebody other than the authors themselves having managed to build it? This made me laugh, as I know where it's coming from; over promise, under deliver. Of course, it works; in theory. But in practice, well, that could take /you /the user, a lifetime.
Re: Zoom- best practice?
to...@tuxteam.de (12020-06-07): > No. But I haven't tried, so... Well, me neither. But if I have not tried personally, I know people who have tried and failed. If only the authors can build a software, it cannot be considered Libre Software, since part of the source code is missing. Open Source at best. We have to acknowledge: there are no Libre Software solutions for videoconferencing. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Zoom- best practice?
On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote: > to...@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? No. But I haven't tried, so... Cheers -- t signature.asc Description: Digital signature
Re: Zoom- best practice?
On Sun 07 Jun 2020 at 20:37:55 +0200, Nicolas George wrote: > to...@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? The OP says: > Family is using Zoom, International. > They will use Zoom, and I need to participate. If he wishes to participate he uses Zoom. There isn't any interworking between it and other similar programs. Discussion about Zoom can go on endlessly. It doesn't alter the technical fact. -- Brian.
Re: Zoom- best practice?
On Sunday, June 07, 2020 02:23:04 PM Seeds Notoneofmy wrote: > I just looked into this, having had an issue with Zoom recently. And it > seems it allows for installing the server locally? Am I understanding > this right, that one can have their own BBB server and provide access to > others to connect to and share/chat? > > If that's the case, why would anyone need skype, zoom, etc? Only would > need to secure one's own BBB server properly. Can someone confirm, please? Without knowing for sure, I believe I've read that a jitsi server can be local, and it wouldn't surprise me that a BBB server can be local. My guess is, though, that the server needs more bandwidth than any of the participants including the moderator / host (on a system like zoom). > https://github.com/bigbluebutton/bbb-install
Re: Zoom- best practice?
to...@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? Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Zoom- best practice?
On Sun, Jun 07, 2020 at 08:23:04PM +0200, Seeds Notoneofmy wrote: > On 6/5/20 8:57 PM, Peter Ehlert wrote: > > >>Look into Big Blue Button and see if you can get your family to try > >>that instead. > > > >bigbluebutton is interesting. Thanks for the thought. > > > >Many family members use Zoom, and like me, are past seven decades. > >Several of the younger set use Zoom also. > >I think I will not suggest change, I am the lone wolf. > > > I just looked into this, having had an issue with Zoom recently. And it > seems it allows for installing the server locally? Am I understanding > this right, that one can have their own BBB server and provide access to > others to connect to and share/chat? > > If that's the case, why would anyone need skype, zoom, etc? Only would > need to secure one's own BBB server properly. Can someone confirm, please? Yes, the server is free software. As is Jitsi's. So you can get the source, build yourself or download pre-built thingies. There are fairly recent articles on both of them over at lwn: Jitsi: https://lwn.net/Articles/815751/ BigBlueButton: https://lwn.net/Articles/817146/ Cheers -- t signature.asc Description: Digital signature
Re: Zoom- best practice?
There's also barnard for the linux command line users sometimes needs compiling using go. On Sun, 7 Jun 2020, Admin4 wrote: > Date: Sun, 7 Jun 2020 14:00:19 > From: Admin4 > To: debian-user@lists.debian.org > Subject: Re: Zoom- best practice? > Resent-Date: Sun, 7 Jun 2020 18:00:35 + (UTC) > Resent-From: debian-user@lists.debian.org > > btw. if audio + chat WOULD be sufficient (it can handle a lot of > participants) > > try mumble! :) > > https://sourceforge.net/projects/mumble/ > > the Android App is called "plumble" > > https://f-droid.org/en/packages/com.morlunk.mumbleclient/ > > * Client + Server is 100% Open Source > * mumble server is easy to setup > * mumble client is also pretty easy to setup > o headphones / headset recommended > * encrypted communication (128 bit OCB-AES128) > > apt update > > # server > > apt install murmur; > > # client > > apt install mumble; > > give it a call: > > https://audio-konferenz-server.de/ > > (sever is running CentOS X-D but Client is Debian 10 :) ) > > just 4 info > > On 6/7/20 3:42 PM, Peter Ehlert wrote: > > > > On 6/6/20 10:00 PM, Keith bainbridge wrote: > >> On 6/6/20 3:32 am, john doe wrote: > >>> On 6/5/2020 6:28 PM, Peter Ehlert wrote: > >>>> Family is using Zoom, International. > >>>> They will use Zoom, and I need to participate. > >>>> > >>>> I use Debian Mate Stable, and Firefox ESR > >>>> > >>>> I am concerned about security, duh! > >>>> Looking for ideas. > >>>> > >>>> my current thoughts, in order of preference: > >>>> > >>>> 1. Use a separate Debian alongside my daily driver, and use Only > >>>> for the > >>>> Zoom meetings > >>>> > >>> > >>> I would install a Debian VM for Zoom and alike software. > >>> > >>> --? > >>> John Doe > >>> > >> > >> > >> I did too - until somebody suggested firejail. > > > > I am not a Chromium user... and I don't like to fight the VMs > > > > Firefox does have a number of addon privacy tools... > > this one looks interesting: https://add0n.com/privacy-settings.html > >> > >> I always got prompts to install add-ons in chromium. > >> > > > --
Re: Zoom- best practice?
On 6/5/20 8:57 PM, Peter Ehlert wrote: Look into Big Blue Button and see if you can get your family to try that instead. bigbluebutton is interesting. Thanks for the thought. Many family members use Zoom, and like me, are past seven decades. Several of the younger set use Zoom also. I think I will not suggest change, I am the lone wolf. I just looked into this, having had an issue with Zoom recently. And it seems it allows for installing the server locally? Am I understanding this right, that one can have their own BBB server and provide access to others to connect to and share/chat? If that's the case, why would anyone need skype, zoom, etc? Only would need to secure one's own BBB server properly. Can someone confirm, please? https://github.com/bigbluebutton/bbb-install
Re: Zoom- best practice?
On 6/5/20 7:09 PM, Greg Wooledge wrote: I did not test with Chromium or Firefox or anything else. Just tried it two days ago on Firefox. It was a disaster. No sound. And screensharing did not work, at all.
Re: Zoom- best practice?
btw. if audio + chat WOULD be sufficient (it can handle a lot of participants) try mumble! :) https://sourceforge.net/projects/mumble/ the Android App is called "plumble" https://f-droid.org/en/packages/com.morlunk.mumbleclient/ * Client + Server is 100% Open Source * mumble server is easy to setup * mumble client is also pretty easy to setup o headphones / headset recommended * encrypted communication (128 bit OCB-AES128) apt update # server apt install murmur; # client apt install mumble; give it a call: https://audio-konferenz-server.de/ (sever is running CentOS X-D but Client is Debian 10 :) ) just 4 info On 6/7/20 3:42 PM, Peter Ehlert wrote: > > On 6/6/20 10:00 PM, Keith bainbridge wrote: >> On 6/6/20 3:32 am, john doe wrote: >>> On 6/5/2020 6:28 PM, Peter Ehlert wrote: >>>> Family is using Zoom, International. >>>> They will use Zoom, and I need to participate. >>>> >>>> I use Debian Mate Stable, and Firefox ESR >>>> >>>> I am concerned about security, duh! >>>> Looking for ideas. >>>> >>>> my current thoughts, in order of preference: >>>> >>>> 1. Use a separate Debian alongside my daily driver, and use Only >>>> for the >>>> Zoom meetings >>>> >>> >>> I would install a Debian VM for Zoom and alike software. >>> >>> -- >>> John Doe >>> >> >> >> I did too - until somebody suggested firejail. > > I am not a Chromium user... and I don't like to fight the VMs > > Firefox does have a number of addon privacy tools... > this one looks interesting: https://add0n.com/privacy-settings.html >> >> I always got prompts to install add-ons in chromium. >> >
Re: Zoom- best practice?
On 6/6/20 10:00 PM, Keith bainbridge wrote: On 6/6/20 3:32 am, john doe wrote: On 6/5/2020 6:28 PM, Peter Ehlert wrote: Family is using Zoom, International. They will use Zoom, and I need to participate. I use Debian Mate Stable, and Firefox ESR I am concerned about security, duh! Looking for ideas. my current thoughts, in order of preference: 1. Use a separate Debian alongside my daily driver, and use Only for the Zoom meetings I would install a Debian VM for Zoom and alike software. -- John Doe I did too - until somebody suggested firejail. I am not a Chromium user... and I don't like to fight the VMs Firefox does have a number of addon privacy tools... this one looks interesting: https://add0n.com/privacy-settings.html I always got prompts to install add-ons in chromium.
Re: Zoom- best practice?
On 6/6/20 3:32 am, john doe wrote: On 6/5/2020 6:28 PM, Peter Ehlert wrote: Family is using Zoom, International. They will use Zoom, and I need to participate. I use Debian Mate Stable, and Firefox ESR I am concerned about security, duh! Looking for ideas. my current thoughts, in order of preference: 1. Use a separate Debian alongside my daily driver, and use Only for the Zoom meetings I would install a Debian VM for Zoom and alike software. -- John Doe I did too - until somebody suggested firejail. I always got prompts to install add-ons in chromium. -- Keith Bainbridge keithr...@gmail.com 0447 667468
Re: Zoom- best practice?
On Sat, Jun 6, 2020 at 10:49 AM wrote: > On Sat, Jun 06, 2020 at 01:06:02PM +0200, Alex Mestiashvili wrote: > > > [...] Btw BBB is also far away from a secure platform imho. > > Quite possible. Still, you can choose a server run by people you > trust. And the developers seem to be quite responsive. > This would be why OpenStreetMap recently switched to BBB.
Re: Zoom- best practice?
On Sat, Jun 06, 2020 at 01:06:02PM +0200, Alex Mestiashvili wrote: > [...] Btw BBB is also far away from a secure platform imho. Quite possible. Still, you can choose a server run by people you trust. And the developers seem to be quite responsive. Cheers -- t signature.asc Description: Digital signature
Re: Zoom- best practice?
On 6/6/20 12:13 AM, Linux-Fan wrote: > Peter Ehlert writes: > >> Family is using Zoom, International. >> They will use Zoom, and I need to participate. >> >> I use Debian Mate Stable, and Firefox ESR >> >> I am concerned about security, duh! >> Looking for ideas. >> >> my current thoughts, in order of preference: >> >> 1. Use a separate Debian alongside my daily driver, and use Only for the Zoom >> meetings >> >> 2. Sandbox? (but how can I do that?) >> >> 3. Use a different browser > > [...] > > Hello, > > best practice is certainly using different software (Big Blue Button has been > mentioned, Jitsi works OK for small groups, say ~10 persons, too), but there > are > cases where I am not asked to decide the software. At least, Zoom works on > Linux > whereas e.g. Skype for Business doesn't despite claiming to have a „Web App“? > > I am also using Zoom (not by preference, see above) and thought about ways to > isolate it for which I basically came up with a similar list to yours. Here is > what I did so far: > > * Zoom inside a VM works well here. I use Virt-Manager + KVM and > audio works flawlessly without the need for much additional configuration. > I only added this line to .config/pulse/daemon.conf: > > flat-volumes = no > > This makes sure that opening the VM does not reset volume back to 100% > which is dangerously loud on my sound card, see > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674936> :) > > * As a fallback solution, I setup a sandbox for chromium using firejail > (package firejail) with a custom profile (attached for those interested). > > If you do not like the VM approach, you might consider a sandbox around > the zoom client. Of course, it is possible to use the sandbox inside the > VM, too. I doubt the added security of combining VM+sandbox is worth the > added complexity, though. > > Using an entirely different system is certainly an option security-wise (if > network isolation is considered properly), but might have some additional > practical limitations. > > HTH > Linux-Fan Thanks for sharing firejail profile, however doesn't it work in the browser? It is really hidden though, but if you decline 2 times software installation in the Chrome you get a link to join zoom via browser. That's what I had to use a couple of times. The best practice is to avoid installing zoom debian package at all. Btw BBB is also far away from a secure platform imho.
Re: Zoom- best practice?
On Sat, Jun 06, 2020 at 12:13:28AM +0200, Linux-Fan wrote: [...] > Hello, > > best practice is certainly using different software +100 [...] >(Big Blue Button > has been mentioned, Jitsi works OK for small groups, say ~10 > persons, too) [...] FWIW, it seems to be an infrastructure question. The Munich Freifunk folks [1] (sorry, in German) are experimenting with cascaded Jitsi video bridges and report conferences of up to ~200. Here [2] (sorry, javascript infested, but colorful stats) is their current stats page. So it seems worth investing into that. Again a reason more to foster strong tech groups (local Linux users, hackerspaces, what not) around you. Cheers [1] https://ffmuc.net/ [2] https://stats.ffmuc.net/d/U6sKqPuZz/meet-stats?orgId=1&refresh=1m -- t signature.asc Description: Digital signature
Re: Zoom- best practice?
On 6/5/20 13:48, Brian wrote: > On Fri 05 Jun 2020 at 09:28:21 -0700, Peter Ehlert wrote: > >> Family is using Zoom, International. >> They will use Zoom, and I need to participate. > > Seems straightforward. Just get on with it. > >> I use Debian Mate Stable, and Firefox ESR >> >> I am concerned about security, duh! > > Really? Just get on with communicating with your family. That's a bit > more important than worrying about possible non-existent issues and > basing your actions on them. > I'll second this and offer a couple of additional comments. On Debian Buster with Gnome, pretty vanilla except for google-chrome and some R packages from r-cran, I downloaded the Zoom .deb package and installed it [1], as root, in /opt, with no dependency issues that another responder noted might interfere. The only issue of any consequence was that on a 15 inch 3840 x 2160 screen, the boxes were quite small and the print in the window titles and popups was too small to read w/o a strong magnifier. It took a while, but of searching in Zoom's FAQs provided a solution [2]. Security issues whooped up in the media seem to fall mostly into one or more of three boxes: Affect (or are known to affect) only Macs; Have been corrected, some quite a while ago; User error (e. g., setting up for zoom-bombing by failing to use a password, using an obvious password, or letting the password leak. Some appear unworthy of much concern, like early use of 128 bit AES for session encryption. Clearly of interest if a meeting concerns national security or other public policy matters, or important organization or personal privacy matters. Most personal/family communications probably do not involve such things. Running it in a VM might improve security, although one responder mentioned sound pass-through as an issue, and setup, at best, would be more work. Dedicated hardware, if you have it probably would be a better choice for isolation. An alternative would be to install Debian and Zoom on a USB key or drive. I would expect USB2 to be adequate, although maybe a bit sluggish at times. You also could put the machine on a guest WiFi to isolate it from other machines. As with all software, keep it up to date. With Zoom's present rate of update, that could be as often as before every use. All the other users also should keep theirs up to date. Zoom users, of course, should be aware (a) that free subscriptions are not encrypted end-to-end and (b) Zoom cooperates with law enforcement agencies, probably meaning that they will allow interception if presented with an appropriate warrant (in the US; other nations' laws are different). Cloud session storage might also be an issue, although the Debian client session recording appears to be local when activated. Regards, Tom Dial [1] Using apt install, and the absolute path, instead of dpkg, may have helped resolve dependencies; I have seen reports to that effect. [2] scaleFactor=2 in .config/zoomus.conf instead of default scaleFactor=1.
Re: Zoom- best practice?
>> Family is using Zoom, International. >> They will use Zoom, and I need to participate. > >Seems straightforward. Just get on with it. Don't. Zoom is not necessary to stay in touch with family. If you cannot get another video conferencing provider, use a phone. But do not prove to providers such as Zoom that you need them for your most intimate needs — it fuels their wrong-doing. Also, I had the impression that this were a technical support mailing list, not a family therapist forum. -nik
Re: Zoom- best practice?
Peter Ehlert writes: Family is using Zoom, International. They will use Zoom, and I need to participate. I use Debian Mate Stable, and Firefox ESR I am concerned about security, duh! Looking for ideas. my current thoughts, in order of preference: 1. Use a separate Debian alongside my daily driver, and use Only for the Zoom meetings 2. Sandbox? (but how can I do that?) 3. Use a different browser [...] Hello, best practice is certainly using different software (Big Blue Button has been mentioned, Jitsi works OK for small groups, say ~10 persons, too), but there are cases where I am not asked to decide the software. At least, Zoom works on Linux whereas e.g. Skype for Business doesn't despite claiming to have a „Web App“? I am also using Zoom (not by preference, see above) and thought about ways to isolate it for which I basically came up with a similar list to yours. Here is what I did so far: * Zoom inside a VM works well here. I use Virt-Manager + KVM and audio works flawlessly without the need for much additional configuration. I only added this line to .config/pulse/daemon.conf: flat-volumes = no This makes sure that opening the VM does not reset volume back to 100% which is dangerously loud on my sound card, see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674936> :) * As a fallback solution, I setup a sandbox for chromium using firejail (package firejail) with a custom profile (attached for those interested). If you do not like the VM approach, you might consider a sandbox around the zoom client. Of course, it is possible to use the sandbox inside the VM, too. I doubt the added security of combining VM+sandbox is worth the added complexity, though. Using an entirely different system is certainly an option security-wise (if network isolation is considered properly), but might have some additional practical limitations. HTH Linux-Fan include /etc/firejail/disable-programs.inc include /etc/firejail/disable-passwdmgr.inc include /etc/firejail/disable-common.inc include /etc/firejail/disable-devel.inc include /etc/firejail/disable-interpreters.inc include /etc/firejail/whitelist-var-common.inc blacklist /var/log blacklist /var/www blacklist /boot blacklist /root blacklist /opt blacklist /srv blacklist /media apparmor netfilter disable-mnt private-dev # problems with multiple browser sessions private-tmp #caps.keep sys_chroot,sys_admin nodbus nodvd nogroups notv #nonewprivs nou2f noexec /tmp env NO_CHROME_KDE_FILE_DIALOG=1 shell none #caps.drop all pgpH3j5Vj51VD.pgp Description: PGP signature
Re: Zoom- best practice?
On Fri 05 Jun 2020 at 09:28:21 -0700, Peter Ehlert wrote: > Family is using Zoom, International. > They will use Zoom, and I need to participate. Seems straightforward. Just get on with it. > I use Debian Mate Stable, and Firefox ESR > > I am concerned about security, duh! Really? Just get on with communicating with your family. That's a bit more important than worrying about possible non-existent issues and basing your actions on them. -- Brian.
Re: Zoom- best practice?
On 6/5/20 9:56 AM, der.hans wrote: Am 05. Jun, 2020 schwätzte Peter Ehlert so: Family is using Zoom, International. They will use Zoom, and I need to participate. I use Debian Mate Stable, and Firefox ESR I am concerned about security, duh! Looking for ideas. my current thoughts, in order of preference: 1. Use a separate Debian alongside my daily driver, and use Only for the Zoom meetings 2. Sandbox? (but how can I do that?) 3. Use a different browser Does zoom work just in the browser without installing software? For me, with Firefox, I had to install a package. It seemed to work ok, two party meeting. That was a month ago. I have to use it in a couple places for work. In my experience, it demands installing software on both debian and Ubuntu. zoom does provide a package with insufficient depends. A few days ago was the second time I used it. I could not get sound. Meeting with 4 connections. using the Phone for voice connection failed. From the Zoom website I grabbed the .deb package and installed it on my disposable system. It seemed to work, and I did not have to give an email. I could not instigate a meeting with that app. I have not asked another to schedule one for me. It also demands a package for android. ciao, der.hans 4. What Me Worry? ... just update and flow with it Thanks, Peter
Re: Zoom- best practice?
On 6/5/20 9:47 AM, Paul Johnson wrote: On Fri, Jun 5, 2020 at 11:45 AM Peter Ehlert <mailto:pe...@sdi-baja.com>> wrote: Family is using Zoom, International. They will use Zoom, and I need to participate. I use Debian Mate Stable, and Firefox ESR I am concerned about security, duh! Looking for ideas. Look into Big Blue Button and see if you can get your family to try that instead. bigbluebutton is interesting. Thanks for the thought. Many family members use Zoom, and like me, are past seven decades. Several of the younger set use Zoom also. I think I will not suggest change, I am the lone wolf.
Re: Zoom- best practice?
On Fri, 5 Jun 2020 09:28:21 -0700 Peter Ehlert wrote: > Family is using Zoom, International. > They will use Zoom, and I need to participate. Zoom also has a native client. Consider using a virtual machine. You will need to get sound to and from the VM, which I don't believe works on qemu. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Zoom- best practice?
On 6/5/2020 6:28 PM, Peter Ehlert wrote: Family is using Zoom, International. They will use Zoom, and I need to participate. I use Debian Mate Stable, and Firefox ESR I am concerned about security, duh! Looking for ideas. my current thoughts, in order of preference: 1. Use a separate Debian alongside my daily driver, and use Only for the Zoom meetings I would install a Debian VM for Zoom and alike software. -- John Doe
Re: Zoom- best practice?
On Fri, Jun 05, 2020 at 04:56:00PM +, der.hans wrote: > Does zoom work just in the browser without installing software? > > I have to use it in a couple places for work. In my experience, it demands > installing software on both debian and Ubuntu. zoom does provide a package > with insufficient depends. > > It also demands a package for android. It works in the browser without installing anything, at least in Google Chrome. I did not test with Chromium or Firefox or anything else. However, it does require you to register, and then they spam you with email several times a week.
Re: Zoom- best practice?
Am 05. Jun, 2020 schwätzte Peter Ehlert so: Family is using Zoom, International. They will use Zoom, and I need to participate. I use Debian Mate Stable, and Firefox ESR I am concerned about security, duh! Looking for ideas. my current thoughts, in order of preference: 1. Use a separate Debian alongside my daily driver, and use Only for the Zoom meetings 2. Sandbox? (but how can I do that?) 3. Use a different browser Does zoom work just in the browser without installing software? I have to use it in a couple places for work. In my experience, it demands installing software on both debian and Ubuntu. zoom does provide a package with insufficient depends. It also demands a package for android. ciao, der.hans 4. What Me Worry? ... just update and flow with it Thanks, Peter -- # https://www.LuftHans.com https://www.PhxLinux.org # C'est la Net - der.hans
Re: Zoom- best practice?
On Fri, Jun 5, 2020 at 11:45 AM Peter Ehlert wrote: > Family is using Zoom, International. > They will use Zoom, and I need to participate. > > I use Debian Mate Stable, and Firefox ESR > > I am concerned about security, duh! > Looking for ideas. > Look into Big Blue Button and see if you can get your family to try that instead.
Zoom- best practice?
Family is using Zoom, International. They will use Zoom, and I need to participate. I use Debian Mate Stable, and Firefox ESR I am concerned about security, duh! Looking for ideas. my current thoughts, in order of preference: 1. Use a separate Debian alongside my daily driver, and use Only for the Zoom meetings 2. Sandbox? (but how can I do that?) 3. Use a different browser 4. What Me Worry? ... just update and flow with it Thanks, Peter
Linphone x Zoom.
A Zoom invitation includes sip:12345678...@zoomcrc.com. When the session is open and Linphone is given the URL it reports "Temporarily Unavailable". Does anyone have success with a similar connection? Thanks,... Peter E. -- https://en.wikibooks.org/wiki/Medical_Machines https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140Bcc: peter at easthope. ca
Re: Zoom conferencing
On Sat, Feb 29, 2020 at 9:08 PM Joel Rees wrote: > (I hope no one gets upset about double posting debian and ubuntu users > lists.) > > Questions about zoom -- www.zoom.us > > Anyone using it? > > Issues? > > Known reasons they don't put it in the general repositories? > Hi Joel, So as it happens, i need to use zoom this next Monday (2020-03-23), so i downloaded it, and with the help of the list (songbird!) got it installed. It is not my choice, although in the past i have used it in work, where it was also not my choice. Of course i'd like to use only free software to help build a better world. (Not cc'ing the ubuntu list because i'm sort of unsure about what the proper netiquette is.) dan
Re: Zoom conferencing
On 2020-03-19 18:39, Anil Felipe Duggirala wrote: I have installed the flatpak with the latest version. I am running Debian 10 and Gnome. When trying to share the screen a message comes up saying that screen sharing is only available in Gnome on Wayland on Debian 9+,, and screen sharing does not start. I am baffled by this. Did you install this from the flatpak?? Yes, flatpak from flathub.org. I don't think any kind of screen sharing works in Wayland. I am using X11. (KDE Plasma, but that's irrelevant.) There should be an option to switch to Gnome X11 when logging in. -- Nazar
Re: Zoom conferencing
Hello Nazar, I have installed the flatpak with the latest version. I am running Debian 10 and Gnome. When trying to share the screen a message comes up saying that screen sharing is only available in Gnome on Wayland on Debian 9+,, and screen sharing does not start. I am baffled by this. Did you install this from the flatpak?? thank you, Anil On Tue, 2020-03-03 at 06:41 +0100, Nazar Zhuk wrote: > On 2020-02-29 23:08, Joel Rees wrote: > > (I hope no one gets upset about double posting debian and ubuntu > > users > > lists.) > > > > Questions about zoom --www.zoom.us > > > > Anyone using it? > > > > Issues? > > > > Known reasons they don't put it in the general repositories? > > > > As others have pointed out, it's proprietary and will never be in > Debian and there are superior open-source alternatives. > > If the choice is not yours though, there is a flatpak for it: > https://flathub.org/apps/details/us.zoom.Zoom. It's kept isolated > from your system and it works. I haven't used video, but no issues > with audio and screen sharing. >
Re: Zoom conferencing
On 3/1/20 12:08 AM, Joel Rees wrote: Questions about zoom -- www.zoom.us <http://www.zoom.us> Issues? Screen and window sharing don't work with Wayland (yet?), requiring a switch to Xorg. I only experienced this on Fedora using the Flatpak, but presume it's not specific to the platform. Sharing a window and giving control worked fine, as did chat, voice and other features. -- -Andrew J. Caines- Unix Systems Architect a.j.cai...@halplant.com "Machines take me by surprise with great frequency" - Alan Turing
Re: Zoom conferencing
On 2020-02-29 23:08, Joel Rees wrote: (I hope no one gets upset about double posting debian and ubuntu users lists.) Questions about zoom --www.zoom.us Anyone using it? Issues? Known reasons they don't put it in the general repositories? As others have pointed out, it's proprietary and will never be in Debian and there are superior open-source alternatives. If the choice is not yours though, there is a flatpak for it: https://flathub.org/apps/details/us.zoom.Zoom. It's kept isolated from your system and it works. I haven't used video, but no issues with audio and screen sharing. -- Nazar
Re: Zoom conferencing
On 2/29/20 10:08 PM, Joel Rees wrote: > (I hope no one gets upset about double posting debian and ubuntu users > lists.) > > Questions about zoom -- www.zoom.us <http://www.zoom.us> > > Anyone using it? > > Issues? > > Known reasons they don't put it in the general repositories? zoom is proprietary software as others have noted, so will never be in Debian. I use it daily without any issues to attend a meeting with audio and shared screen from a presenter and a text chat window where I can participate. I have not used the microphone nor webcam options. zoom launches from a terminal or your regular menu pull-down and does not require any browser. Audio works well thru pulse audio which I adjust with pavucontrol. Running debian stable 10.3 zoom Linux Client Version is 3.5.352596.0119 an update is avail which I'll install now. Regards, Ralph signature.asc Description: OpenPGP digital signature
Re: Zoom conferencing
On Sun, Mar 01, 2020 at 12:46:24PM -0500, Henning Follmann wrote: On Sun, Mar 01, 2020 at 02:08:27PM +0900, Joel Rees wrote: If you are interested in a free video/ voice conference tool look at jitsi. Jitsi (or perhaps it is "jitsi-meet" has a free web-accessible service which does not require the installation of anything; it works nicely. I seem to recall that there are technical problems with jitsi on Buster which may not be resolved until Debian 11. Meanwhile, jitsi has a free Debian package, if you do not mind installing from the Jitsi repository. RLH
Re: Zoom conferencing
On Sun, Mar 01, 2020 at 02:08:27PM +0900, Joel Rees wrote: > (I hope no one gets upset about double posting debian and ubuntu users > lists.) > > Questions about zoom -- www.zoom.us > > Anyone using it? > Maybe, not me tho > Issues? It's proprietary > > Known reasons they don't put it in the general repositories? It's proprietary If you are interested in a free video/ voice conference tool look at jitsi. It's what they use at matrix for their voice. -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: Zoom conferencing
On Sun, 1 Mar 2020 10:15:45 -0700 Charles Curley wrote: > Rather than install Chrome, consider installing chromium. I believe it > is the open source base of Chromium. Sorry. I believe chromium is the open source base of Chrome. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Zoom conferencing
On Mon, 2 Mar 2020 03:44:27 +1100 David wrote: > If anyone can advise me how to make this version of Firefox work > on current Debian buster or stretch, I will be grateful to be > corrected. I've had to reluctantly install the Zoom client, > preferring that compromise to installing Chrome. Rather than install Chrome, consider installing chromium. I believe it is the open source base of Chromium. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Zoom conferencing
On Sun, 1 Mar 2020 at 23:41, Dan Ritter wrote: > If someone sends you a link to use their service, they have a semi-hidden > web client available -- take the conference identifier from the regular > URL, and append it to > > https://zoom.us/wc/join/ > > This works in Firefox and Chromium. My experience on Debian is that while the web client used to work in older versions of Firefox, the web client when tested at https://zoom.us/test now refuses to allow microphone access in the Debian version (68.5.0esr (64-bit)) of Firefox, and advises to use Google Chrome. If anyone can advise me how to make this version of Firefox work on current Debian buster or stretch, I will be grateful to be corrected. I've had to reluctantly install the Zoom client, preferring that compromise to installing Chrome. Also https://support.zoom.us/hc/en-us/articles/214629443-Zoom-Web-Client says: """ **Joining computer audio on Firefox and Safari is only available for webinar attendees. """ I assume that a "webinar attendee" is distinct from a "meeting", according to their use of those words.
Re: Zoom conferencing
On Sun, Mar 01, 2020 at 08:07:58AM -0500, rhkra...@gmail.com wrote: > On Sunday, March 01, 2020 07:41:18 AM Dan Ritter wrote: > > If someone sends you a link to use their service, they have a semi-hidden > > web client available -- > > I guess that should be web server? > > I mean, unless this is like the backwards (to me, and I'm familiar with the > justification / arguments -- to me a client serves me, not some software) > definitions for client and server used in X, things like firefox and chromium > are clients, not servers. > It is a client in the sense that it is a program that allows you, the user, to connect to a server which is providing the necessary support for a conference meeting to take place. It is also a server in the sense that you must connect to a webserver in order to access it, just as Java applets and Flash apps are generally hosted on webservers. That particular distinction, however, is irrelevant to the vast majority of users. Regards, -Roberto -- Roberto C. Sánchez
Re: Zoom conferencing
rhkra...@gmail.com wrote: > On Sunday, March 01, 2020 07:41:18 AM Dan Ritter wrote: > > If someone sends you a link to use their service, they have a semi-hidden > > web client available -- > > I guess that should be web server? > > I mean, unless this is like the backwards (to me, and I'm familiar with the > justification / arguments -- to me a client serves me, not some software) > definitions for client and server used in X, things like firefox and chromium > are clients, not servers. It's a client for their service that operates entirely in your web browser, and is handed to you each time from their web server. Client-server distinctions are all a matter of perspective. -dsr-
Re: Zoom conferencing
On Sunday, March 01, 2020 07:41:18 AM Dan Ritter wrote: > If someone sends you a link to use their service, they have a semi-hidden > web client available -- I guess that should be web server? I mean, unless this is like the backwards (to me, and I'm familiar with the justification / arguments -- to me a client serves me, not some software) definitions for client and server used in X, things like firefox and chromium are clients, not servers. > take the conference identifier from the regular > URL, and append it to > > https://zoom.us/wc/join/ > > This works in Firefox and Chromium. > > -dsr-
Re: Zoom conferencing
Joel Rees wrote: > (I hope no one gets upset about double posting debian and ubuntu users > lists.) > > Questions about zoom -- www.zoom.us > > Anyone using it? > > Issues? > > Known reasons they don't put it in the general repositories? It's not free in any sense. If someone sends you a link to use their service, they have a semi-hidden web client available -- take the conference identifier from the regular URL, and append it to https://zoom.us/wc/join/ This works in Firefox and Chromium. -dsr-
Re: Zoom conferencing
[ replying only where I am subscribed ] Quoting Joel Rees (2020-03-01 06:08:27) > (I hope no one gets upset about double posting debian and ubuntu users > lists.) > > Questions about zoom -- www.zoom.us > > Anyone using it? > > Issues? > > Known reasons they don't put it in the general repositories? Zoom is non-free. You might find relevant some of my notes on voice/video chat tools and services here: https://source.redpill.dk/media-stream-hosting.git/tree/README.md - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Zoom conferencing
On Sun, Mar 01, 2020 at 02:08:27PM +0900, Joel Rees wrote: > (I hope no one gets upset about double posting debian and ubuntu users > lists.) > > Questions about zoom -- www.zoom.us > > Anyone using it? > > Issues? > > Known reasons they don't put it in the general repositories? Perhaps because it ain't free software? -- t signature.asc Description: Digital signature
Zoom conferencing
(I hope no one gets upset about double posting debian and ubuntu users lists.) Questions about zoom -- www.zoom.us Anyone using it? Issues? Known reasons they don't put it in the general repositories?
Re: Logitech Quickcam Zoom Webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've done a quick write up and put it up for now so that a). I can find it in future; and b). someone else might find it useful. If anyone is interested in taking a look it can be found at: http://www.bjornballard.co.uk/os/logitech-pwc.html When I have a little more time on my hands I'll expand on it too. Once again, many thanks Steve. Beej :o) Steve Kemp wrote: > > Great. I keep meaning to write it up in more detail, since that > message was pretty terse and mostly posted from memory, but I'm glad > you managed to follow it ok. > > Hmmm its always worked as-is for me, I guess I just got lucky :) > > Steve - -- Björn BallardOpenPGP Key ID: 0x229738E2 http://www.bjornballard.co.uk/ Debian GNU/Linux Testing / Kernel i386 2.6.16 / KDE 3.5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFALfEMRMvXyKXOOIRAuYTAJ4pxEAbVlVqqbNW1o4ujynwirgKFwCeM0b4 bFCPkpQ3559yMM7cnjZwv9k= =ydKi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logitech Quickcam Zoom Webcam
On Thu, Sep 07, 2006 at 08:09:23PM +0100, Bj?rn Ballard wrote: > Many thanks Steve. Worked a treat! I'll take note in future to search > debian-devel. Great. I keep meaning to write it up in more detail, since that message was pretty terse and mostly posted from memory, but I'm glad you managed to follow it ok. > One tip other's might appreciate in respect to this camera that I've just > found out. The camera requires RGB to BGR conversion on YUV in some > applications. Hmmm its always worked as-is for me, I guess I just got lucky :) Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logitech Quickcam Zoom Webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Many thanks Steve. Worked a treat! I'll take note in future to search debian-devel. One tip other's might appreciate in respect to this camera that I've just found out. The camera requires RGB to BGR conversion on YUV in some applications. Beej :o) Steve Kemp wrote: > On Thu, Sep 07, 2006 at 05:53:32PM +0100, Björn Ballard wrote: > >> Does anyone have any suggestions or ideas as to how to >> get this to work properly? Or managed to solve this >> themselves in the past? > >http://lists.debian.org/debian-devel/2006/08/msg01010.html > > Steve - -- Björn BallardOpenPGP Key ID: 0x229738E2 http://www.bjornballard.co.uk/ Debian GNU/Linux Testing / Kernel i386 2.6.16 / KDE 3.5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAG5jMRMvXyKXOOIRAs1+AJ0QpG1CK8pGKC+axFkotMuB+ktQ/wCfQT2a t2mQ6b/02TmI02k3Igqmd78= =Dl+J -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logitech Quickcam Zoom Webcam
On Thu, Sep 07, 2006 at 05:53:32PM +0100, Bj?rn Ballard wrote: > Does anyone have any suggestions or ideas as to how to > get this to work properly? Or managed to solve this > themselves in the past? http://lists.debian.org/debian-devel/2006/08/msg01010.html Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/
Logitech Quickcam Zoom Webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, Here's a problem that's been plaguing me all day and try as I may I've not had any luck with the various resources online or several google searches. I've been trying to get my Logitech Quickcam Zoom webcam to work under Debian Testing with the 2.6.16-2 kernel. All I can get in xawtv or gqcam are blank grey or green screens, and altho kopete recognises the webcam is a available on accessing it all that is sent is purple and grey "snow". If requested I will post screenshots. On connecting the webcam dmesg shows: usb 2-2: new full speed USB device using uhci_hcd and address 5 usb 2-2: configuration #1 chosen from 1 choice pwc Logitech QuickCam Zoom USB webcam detected. pwc Registered as /dev/video0. And the /dev/video0 shows as: crw-rw 1 root video 81, 0 2006-09-07 17:42 /dev/video0 My user is a member of the video group. lsmod | grep pwc shows that the pwc module (from the stock Debian kernel) that this webcam uses is loaded correctly: pwc44336 0 compat_ioctl32 1184 1 pwc videodev8640 1 pwc usbcore 110560 5 snd_usb_audio, snd_usb_lib, pwc, uhci_hcd Does anyone have any suggestions or ideas as to how to get this to work properly? Or managed to solve this themselves in the past? All help gratefully received! Many thanks Beej :o) - -- Björn BallardOpenPGP Key ID: 0x229738E2 http://www.bjornballard.co.uk/ Debian GNU/Linux Testing / Kernel i386 2.6.16 / KDE 3.5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAE6MMRMvXyKXOOIRAtUDAJ0RdYd2sXvKgljizUltxWjIeSwWCwCcCYFW E9yAZF+qTAi3FH3O+DVqgIc= =R2uk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: Zoom ADSL 5X Router,Modem,Switch error
-- Forwarded message -- From: Werner Otto <[EMAIL PROTECTED]> Date: Sat, 18 Sep 2004 19:11:38 +0100 Subject: Zoom ADSL 5X Router,Modem,Switch error To: [EMAIL PROTECTED] Hi All, I recently bout a Zoom X5 Router modem. I set it up on Windows XP Pro with no errors. I booted into Debian with no problem and worked 100%. I then logged off and a few days later logged back into Debian and did not work. I am unable to ping any hostname or localhost. I changed nothing. I made sure that my nameserver in /etc/resolv.conf was set to 10.0.0.2. My /etc/network/interfaces file has the line auto dhcp and iface eth0 inet dhcp in it, with the fallback lo interface. The errors that I get at bootup are: DHCPNAK with no active lease 10.0.0.2 DROPPED IN= OUT=eth0 SRC=10.0.0.10 DST=10.0.0.255 LEN=260 TOS=0x00 PREC=0x00 TTL=64 ID=1 DF PROTO=UDP SPT=138 DPT=138 LEN=240. This error sequence seems to display indefinate. I am a newby when it comes to router configuration. Could someone please point me in the right direction? -- Kind Regards Otto -- Kind Regards Werner Otto 07818298666 02087423424 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Zoom ADSL 5X Router,Modem,Switch error
Hi All, I recently bout a Zoom X5 Router modem. I set it up on Windows XP Pro with no errors. I booted into Debian with no problem and worked 100%. I then logged off and a few days later logged back into Debian and did not work. I am unable to ping any hostname or localhost. I changed nothing. I made sure that my nameserver in /etc/resolv.conf was set to 10.0.0.2. My /etc/network/interfaces file has the line auto dhcp and iface eth0 inet dhcp in it, with the fallback lo interface. The errors that I get at bootup are: DHCPNAK with no active lease 10.0.0.2 DROPPED IN= OUT=eth0 SRC=10.0.0.10 DST=10.0.0.255 LEN=260 TOS=0x00 PREC=0x00 TTL=64 ID=1 DF PROTO=UDP SPT=138 DPT=138 LEN=240. This error sequence seems to display indefinate. I am a newby when it comes to router configuration. Could someone please point me in the right direction? -- Kind Regards Otto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ZOOM X4 adsl modem , Apache behind home gateway[SOLVED]
On Mon, Sep 13, 2004 at 12:35:08AM +0300, Hasan wrote: > i change the lines in etc/network/interfaces like this : > > iface eth0 inet static > address 10.0.0.16 > netmask 255.255.255.0 > gateway 10.0.0.2 Make the first line "iface eth0 inet dhcp" and get rid of the other three. Make sure you've got dhclient installed as well. > then in LAN settings in modem , the ip beetween 10.0.0.4 and 10.0.0.15 > so 16 is in outside . That means it'll never be assigned - the opposite of what you want. Make both these entries 10.0.0.16. That way 10.0.0.16 will always be assigned. > then in VIRTUAL HOST in web interface in modem , i change the port 80 to > 10.0.0.16 and leave this the same. -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Re: ZOOM X4 adsl modem , Apache behind home gateway
As previously stated, you will want to use a dynamic dns service such as dyndns.org. If you sign up with them the rest is pretty simple. apt-get install ddclient and after the configuration and installation, since you are behind a gateway, the following line needs to be added to the end of /etc/ddclient.conf use=web, web=checkip.dyndns.org This will ensure it the dyndns service gets your pubic IP. For more info http://jamesallen.dyndns.org:3000/tutorials/dyndns.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ZOOM X4 adsl modem , Apache behind home gateway
On Sun, Sep 12, 2004 at 12:25:28PM -0600, Dean Allen Provins wrote: > On Sun, Sep 12, 2004 at 07:51:15PM +0300, Hasan wrote: > > Hello , > > I want to use apache server , it works at localhost perfect . Bu i have > > the adsl modem zoom x4 . When i click my ip at the browser Home Gateway > > popup appears and ask password. I tried to do Virtual Host section . > > When I set port 80 to my ip , it reset the modem and my ip chages ! How > > can i do this ? I googled and ask in freenode irc but cant find . > > If I understand your situation and question correctly, you want to set > up your Apache web server for access from outside your local network. > As far as I know, and this is based on my experience of a network behind > an ADSL modem and a router (there are several machines connected via > the router to the modem), you need a little more. I have a Zoom X3... > You must direct port 80 traffic to the host running Apache. It appears > that you've tried to do this, but every time the modem is reset, you > get a new IP number. This happens because your ISP is assigning you a > dynamically assigned IP number (via DHCP). You could ask for a static > IP number, but that usually costs more (it does from my ISP). > > The way around this is to use a service which associates a name with > your current IP number. That way, people wanting to connect to your > web server, need only remember an unchaning name. > > There are free services on the 'net which will let you associate a name > of your choice with your current IP. For example, you might choose the > name 'maria' for your PC. At 'www.dyndns.org' (the provider that I use) > you would register that name and associate it with a domain (they have > several from which to choose - I use 'dyndns.org' as the domain name). > Thus, your host might have the name 'maria.dyndns.org'. If every time > you reset your modem, you also redid the name to IP association (and > there are free scripts which will assist you to do this), then users > could always reach your host. The canonical way to do this is with the ddclient package. > Using this procedure may help you solve your problem. It certainly did > for me. What this will do is provide a consistent name by which outside users can find your website. It's not the full story on setting up the Zoom. The Zoom will assign your network card an IP via DHCP. (Not to be confused with your ISP assigning you an IP by DHCP!) You will see entries similar to this in /var/log/syslog: Sep 12 00:16:38 stunted dhclient-2.2.x: DHCPREQUEST on eth1 to 10.0.0.2 port 67 Sep 12 00:16:38 stunted dhclient-2.2.x: DHCPACK from 10.0.0.2 Sep 12 00:16:39 stunted dhclient-2.2.x: bound to 10.0.0.10 -- renewal in 43200 seconds. In this case 10.0.0.10 is the IP assigned via DHCP. I'm assuming you only have one box. 10.0.0.10 is the IP that you need to set the Zoom's "Virtual Server" to point to. This IP may change when you reboot the Zoom. To prevent this go into "LAN Configuration" and select "User Defined" addresses for the DHCP server, then set the "User Defined Start Address" and "...End Address" to the same address - 10.0.0.10 in this example. That should ensure that your "Virtual Server" settings always point at the correct IP. You may also need to deal with some bugs in the modem's firmware. In my case I found that the settings to block external access to the Zoom's FTP and HTTP servers didn't do anything (I've reassigned the Zoom's HTTP server to a different port from the standard 80) and a few other random ports were open for no apparent reason. The workaround is to create additional "Virtual Server" entries for the offending ports to forward them to the Linux box, and make sure the Linux box has those ports closed. -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
