Jitsi 2.0 released
Version 2.0 of the cross-platform open source softphone application Jitsi has been released. An announcement on the XMPP Foundation blog includes some details, such as: "one of the most prominent new features in the 2.0 release is Multiparty Video Conferencing. Such conferences can work in an ad-hoc mode where one of the clients relays video to everyone else, or in cases that require scalability, Jitsi can use the Jitsi Videobridge: an RTP relaying server controlled over XMPP.
" Other changes include support for the royalty-free VP8 and Opus codecs, and support for integrating with Microsoft Outlook. Additional details are listed at the Jitsi site.
Posted Mar 11, 2013 0:29 UTC (Mon)
by codewiz (subscriber, #63050)
[Link] (14 responses)
Posted Mar 11, 2013 10:13 UTC (Mon)
by njwhite (guest, #51848)
[Link] (3 responses)
It also apparently has good encryption support (SRTP & ZRTP), which is too rare in softphones at the moment.
Posted Mar 11, 2013 11:11 UTC (Mon)
by niner (subscriber, #26151)
[Link] (2 responses)
Posted Mar 11, 2013 17:04 UTC (Mon)
by drag (guest, #31333)
[Link]
The only real reason I didn't like it is because it screwed up my microphone. I've had similar problems in the past with application like Audacious and Ekiga going in and trying to probe alsa devices and set volumes and options on their own and screwing my microphones up. Luckily, unlike in the past, I was able to correct it by unplugging and plugging it. But I can't have my voip app jacking up the mic just as soon as I try to answer a phone call.
I really wish they would leave all that stuff up to Pulseaudio and just automatically select 'default' device unless the user specifically choices one. The chances of them actually getting it right is going to be pretty slim.
Posted Mar 11, 2013 17:41 UTC (Mon)
by dashesy (guest, #74652)
[Link]
Posted Mar 11, 2013 16:22 UTC (Mon)
by shmerl (guest, #65921)
[Link] (9 responses)
Posted Mar 11, 2013 19:42 UTC (Mon)
by drag (guest, #31333)
[Link] (2 responses)
Posted Mar 12, 2013 21:01 UTC (Tue)
by daniel (guest, #3181)
[Link] (1 responses)
An alternative, more incremental approach would be to move the non-gui functionality to C++ via JNI. However much JNI sucks, it would probably still end up being an improvement even to the Java version.
Posted Mar 13, 2013 11:10 UTC (Wed)
by drag (guest, #31333)
[Link]
What? So all the Java APIs that they hook into is going to be supported by C++?
Going from Java to C++ actually seems a significant step backwards to me, honestly.
Posted Mar 13, 2013 12:09 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (5 responses)
Posted Mar 13, 2013 13:54 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Oh, no! Let's rewrite the kernel then. C certainly isn't "memory-safe". At least C++ has smart pointers, but since we're starting from scratch, let's write it in Haskell.
But if that's your argument, I argue that any application written in Java probably shouldn't be network-facing these days either…
Posted Mar 13, 2013 17:03 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Of course, right now it's not (yet) feasible because of the sheer size and complexity of Linux.
Posted Mar 16, 2013 1:10 UTC (Sat)
by HelloWorld (guest, #56129)
[Link]
Posted Mar 13, 2013 17:33 UTC (Wed)
by codewiz (subscriber, #63050)
[Link] (1 responses)
> Using a language that isn't memory-safe for an application that will
> face the internet is madness.
Modern C++ programming style isn't as prone to buffer overruns as old-school C was. Containers manage their own memory and expose a relatively safe API. Over the years, C++ has become quite a safe AND efficient language, albeit very hard to learn.
With the advent of smart pointers and RAII, you rarely need to explicitly free memory or close a file. In fact, the worse resource leaks I've seen in the last few years came from dangling references and missing close() calls in dynamic languages.
Posted Mar 16, 2013 0:58 UTC (Sat)
by HelloWorld (guest, #56129)
[Link]
I'd still much rather write an application in C++ than in C, simply because it's so much more expressive. But it's not really any safer. Unless I have very high performance requirements, I'll avoid C++ if at all possible (and C even more so).
Posted Mar 11, 2013 18:27 UTC (Mon)
by callegar (guest, #16148)
[Link] (2 responses)
Posted Mar 14, 2013 0:32 UTC (Thu)
by sjj (guest, #2020)
[Link] (1 responses)
I don't have the somewhat irrational seeming Java hatred some people express in this thread. I don't really care that much what language an app is developed in, even if it's Mono/C# or Java. I just want developers to stop being special snowflakes and stop redesigning widgets or color schemes that clash with the rest of the system.
It's not impossible to create nice looking apps with Java. See Eclipse.
Maybe it looks fine on OS X or Windows.
Posted Mar 16, 2013 20:34 UTC (Sat)
by HelloWorld (guest, #56129)
[Link]
Looks useful...
Looks useful...
Looks useful...
Looks useful...
Looks useful...
Yep, I agree - they should remake the whole thing in C++/Qt.
Looks useful...
Looks useful...
Looks useful...
Looks useful...
Looks useful...
Looks useful...
Looks useful...
A good idea. Microsoft is looking in that direction (see: Singularity, Midori).
Looks useful...
The kernel is a prime example of what I'm talking about. There have been so many vulnerabilities that they don't even bother to document them any longer.
And of course it's impossible to rewrite it in a safer language simply due to the amount of work that has gone into it, so we'll have to live with that. But that doesn't mean we should be making the same old mistakes again and again.
Looks useful...
Looks useful...
STL containers do *not* offer a safe API. Iterators are at the core of the STL, and they expose a completely unsafe API. If you ever use them wrong, they'll invoke undefined behaviour; contrast that with a Java-style approach where iterators throw exceptions when you fail to use them correctly. Heck, the semantics of a std::vector<T>::iterator were deliberately designed so that a typedef to T* is a valid implementation. And what's worse is that while unsafe iterator implementations are fast, it's essentially impossible to implement them safely without a major performance cost.
Any clue on how to change the font? In ubuntu it looks reasonable, but on my kubuntu machines it picks a font that is barely readable.
Jitsi 2.0 released
Jitsi 2.0 released
Jitsi 2.0 released
I don't think Eclipse actually qualifies as nice looking.