Stefan Reinauer wrote:
I never tried the web interface.
We did, it failed us.
What problems did people have with mumble-web, and where was the websockets server running, relative to the mumble server?
It was actually your mumble server.
I didn't have mumble-web. I asked about the web interface, which has failed us at some point, as Patrick wrote.
We used it for one or two meetings, and the sound was choppy and it was basically impossible to have a conversation.
I knew that my mumble server was used, but this feedback only reaches me now. Thanks for letting me know!
Ron once said something completely different; that he couldn't run the (native) client software on his ChromeOS system. That made me interested in getting feedback from mumble-web.
Since I use the server for various meetings with great success I'm interested in investigating what caused the issues for us in coreboot. If anyone can remember having problems and would like to do some testing with me at some point then please get in touch off-list. Thanks!
tturne@codeaurora.org wrote:
Just because I work with OSS doesn't automatically make me a zealot for OSS as the only way to go.
Of course not; it's just the best way to go.
think of the contribution to Coreboot source code this energy could generate instead of spending it on fixing a problem that doesn't need fixing?
I think it's an important problem.
I agree with Stefan that it's not a problem for the coreboot community, but I want to not lose our user experience.
ron minnich wrote:
Unfortunately, the free software meeting systems have not worked out.
Suboptimal solutions need to be re-evaluated, once every few years seems easy.
It can't depend on one person managing the server, or the connection, or the setup.
I think a one person argument is silly, but I agree with the general argument about avoiding single points of failure.
portability in the Linux world seems to mean "works on Ubuntu AND Arch".
Daring extrapolation. Sorry that you've had such bad experience.
We have to see it work everywhere.
A big part of which is to be active.
It makes no sense to push a burden of demonstration for "every possible client" to a single point; that's setting up for failure and sending the message that nothing should improve.
There's also an issue with the premise:
..
What does it really mean
To keep trying.
//Peter
Nobody is stopping anyone from implementing and letting us try something open. I think it's great. I would love to be able to use it.
But some rules apply:
o a lot of us have full time jobs and (in my case at least) a skill set that does not include competence/interest in hacking on meeting software. It has to work for me as EASILY as what we are using today.
o it has to work at least as WELL as what we're using today. So far, every single open source alternative has not come close to meeting that standard.
o And, to reiterate, no single points of failure. It seems to me that anything that depends on one person providing 24x7 availability has a single point of failure by definition. And, in at least one case, we went to have a meeting and the (non-redundant) person running the (non-redundant) server connected to the (non-redundant) network was not around. No meeting occurred. That's a failure.