They are very lively, and do useful work.
This year, there will be a talk about Speech-to-Text in Jitsi Meet > https://fosdem.org/2018/schedule/event/jitsi/
Happening in Brussels, Belgium on 3 & 4 February 2018 ;)
I figured it was going to be closed up or slowly killed off after atlassian took over. Pleasantly surprised it's doing better.
I recently buidling riot for F-Droid completely from source, which includes the jitsi-meet android library. So added the jitsi app should not be too complicated hopefully.
It also would not be the software to install on my grandmas pc because of the many important java updates which are needed. The automatic installation of a browser plugin i don't need and which makes it even more vulnerable.
I think if Android would not be using Java it would have died years ago.
On the other hand. Jitsi still great software. Open source and all.
I think you're seriously underestimating the amount of enterprise software running on Java for decades now. Not only it's not going away, but the language itself and its ecosystem are evolving. Slowly, but in the domain of programming languages that are actually being widely used slow progress is a good thing.
Java on the server is a safe language. I agree that any browser plugin affects security and usability negatively, and the Java browser plugin was a nightmare.
Recently I have migrated a large application from RedHat 6 to RedHat 7. A lot of code in Ada, C++, Java (all using corba), many scripts in shell, Perl, Awk, make. Most of the code changes needed were in C++.
Most of the new applications here are developed in java or C#.
Anyone know of a website that maintains a ranking of video chat services, in terms of audio quality?
a) background noise reduction
b) echo/feedback cancellation
c) input latency
My personal list, best to worst, in respect to my requirements above:
WhatsApp audio call
Software aside, when some attendees will often be in the same location consider using https://www.owllabs.com/meeting-owl. It certainly improves the experience for the remote attendees.
It makes me wonder if the best system would marry PSTN for audio with IP for video and/or screen-sharing.
I wish video-chat services/clients would be totally up-front about the real-time quality of the connection. There are natural pauses in any conversation, and if you're always wondering whether the pause is natural or a result of a few dropped packets, it makes for a very un-natural conversation. This could be as simple as "last transmission received N ms ago" indicator or something, but I'm sure there are more clever solutions.
I don't think this is an "easy" problem to solve, but it's one that I think most video chat services seem to pretend doesn't exist. Or they implicitly blame outside factors ("we can't fix the network") rather than helping customers live with the realities of the internet ("we show you immediately and in real-time when the network isn't what you expect").
(I've not put Jitsi through its paces - would love to know how Jitsi handles the UX around dropped packets.)
There are many utilities that show this info in useful form in the system tray; perhaps some would be able to superimpose it on top of the video conferencing software (like OnTopReplica).
I work in the Cisco Spark team so I'm not unbiased when it comes to Skype but you might have a quality problem on your network connection (and the other participants' connections too) if you're seeing consistent audio issues. Real-time media (audio/video) is very sensitive to delay, jitter, congestion and all the network stuff that normally goes un-noticed with web browsing, and there are still plenty of cases that just can't be covered by error correction.
(This is where having the ability to fall back to PSTN to join a call comes in very handy: if I'm in a coffee shop with a crappy connection, there's a strong chance that my call will be of poor quality so I join with my cell phone instead.)
Otherwise I just use zoom.us
I use appear.in all the time for small meetings and love it. :)
Sadly, even just clicking a link seems to be too far out of many people's comfort zone, which is something that I find it very hard to wrap my head around...
Jitsi Meet on the other hand is pure bliss. The website could use a single-line explanation about what it is though. :D
Pro: does not depend on Java
Con: still buggy
I need this, but after spending months trying to work with rocket chat only to find the few tweaks I need just can't be done (easily, and with a reason (to me) budget) - I gave up.
If I could pay someone $100 to walk me through it a bit, answer a few questions, and guide me to how to mod it to what I need, I'd jump.
I think the last time I looked at jiti there was like a mailing list or something suggested for contacting people(?) - I love email, and don't use fbook.. so that's great, but I just never took that step for whatever reason.
Sadly, one of those "chat with us" boxes on the side that just took you to a faq or offered to sign you up to the mail list might be good in that situation.
Would love to have this working on our servers with a few modifications.
I also host a podcast. Can I use jitsi and record audio, separate tracks for each party?
> Can I use jitsi and record audio, separate tracks for each party?
Nope, we don't have that capability, sorry.
Something you can do is use Jitsi Meet (the WebRTC client) and have the monitored device permanently connected to a meeting room (protected by a password if you are using our public infra) and join the call whenever you want to see the other side.
The windows jitsi desktop client I tried didn't seem to be meant for that.
Could you give specific examples?
>nunez: JIRA is a really nice product, but one's experience with it heavily depends on who "owns" it
>wwalser: the hellish existence [...] where JIRA comes up [is] because of one of three things:
· Your admin(s) set it up once and hasn't bothered to iterate on those workflows
· The business mapped their autonomy stripping processes onto JIRA intentionally [...]
· You're on an instance that is serving too many people with too few resources
source: How Atlassian Built a $10B Growth Engine | https://news.ycombinator.com/item?id=16052743 (2018Jan:226 points,170 comments)
Jira allows for a very rigid, formalised process for everything to be built. Few companies resist the temptation, most go all in while chanting "compliance, compliance, COMPLIANCE!" and as a result you have an environment that is a pain to use, has too many mandatory fields everywhere, one allowed status transition workflow (or one per issue/content/whatever type)- it's bureaucracy as a service.
All that takes a lot of time to set up and makes changes within the organisation even harder, because you have one more thing that makes it rigid.
Regardless of which camp you are in, we have dedicated teams focusing improving Jira performance over the coming few months.
If there is any more information you can provide around your situation, we'd love to hear it in order for us to ensure we fix your specific issue.
At a previous job they switched from a hodgepodge of systems and centralized onto Jira and Confluence and I have longed for it at the places I've worked since. I do realize the cost and maintenance (configuring and customizing it to get the most out of it) requires a lot of upfront attention. My most recent job uses them and although I haven't used either heavily yet, I find the gui way more confusing and feel like the pages are almost comically slow and heavy.
Also, they started rolling out a different (React-based) frontend for Jira several months ago. Can't say that particularly improved Jira's performance, but still... I am not sure viewing them as just a Java shop is fair anymore.
And they also seem to be using graphQL now.
The client side bloat I've noticed are both in visual clutter and performance using the Atlassian hosted version...so I doubt it's related to Java (outside of maybe scaling issues?). I don't doubt they have a modern front-end. It feels like one of those hip, new, modern, chunky sites that take too long to load and I try not to revisit. I don't mean to knock on React or modern frameworks, they have their uses and fill needs, but the end result often isn't a pleasant experience. The version I remember using years ago was a bit slower than most static sites, but almost seemed boring and corporate in use (which is a compliment for something you rely on for your job).
One exceptionally bad example I remember is returning HTML for certain 404s even though caller requested json. It was for missing artifacts among others IIRC.
I think it even has phone-in support (at least for a few minutes...)
1) How easy is it to host this in your own infra, and can you do so 100% without proprietary bits?
2) It seems there is a "call a phone feature" built-in. Neat. Does that have any restrictions or can I use it worldwide to call my friends in other countries.
2) That feature requires that you deploy a service of your own to facilitate this. At this time, meet.jit.si provides this for free for 2 minutes, but if you deploy the service to your own infra you'll need to deploy jigasi and configure a VoIP provider yourself.
And being WebRTC, it needs no plugins on popular desktop webbrowsers. Sadly, mobile ones do not support WebRTC. But their app is open, and works very well.
Anyone else see that?
Alternative instance: https://framatalk.org/
Oh they(I?) forgot one more `sudo apt-get install jitsi`
Unresolved requirements: [[net.java.sip.communicator.argdelegation (R 135.0)] osgi.wiring.package; (osgi.wiring.package=org.jitsi.util)]
overall very poor experience.
This does not include the older 'jitsi' named softphone / voip client, meaning there will be no jitsi command that can be executed.
Installation of jitsi-meet was straightforward for me, exactly as oulined on their page:
- first, add their repository to your apt sources.list
- then apt update && apt upgrade
- then apt install jitsi-meet
You should end up with a running web server hosting your own jitsi-meet instance.
I've installed it with a letsencrypt cert... you have to convert it to pkcs#12 with openssl and move it to /etc/jitsi/videobridge/ .
org.osgi.framework.BundleException: Unable to resolve net.java.sip.communicator.shutdowntimeout
org.osgi.framework.BundleException: Unable to resolve net.java.sip.communicator.plugin.simpleaccreg