User: Password:
|
|
Subscribe / Log in / New account

Looks useful...

Looks useful...

Posted Mar 11, 2013 0:29 UTC (Mon) by codewiz (subscriber, #63050)
Parent article: Jitsi 2.0 released

...too bad it's written in Java and the GUI looks ugly enough to be built with Swing.


(Log in to post comments)

Looks useful...

Posted Mar 11, 2013 10:13 UTC (Mon) by njwhite (guest, #51848) [Link]

The java thing puts me off as well. I wouldn't call the GUI ugly, though; https://jitsi.org/Main/Screenshots

It also apparently has good encryption support (SRTP & ZRTP), which is too rare in softphones at the moment.

Looks useful...

Posted Mar 11, 2013 11:11 UTC (Mon) by niner (subscriber, #26151) [Link]

I'd call it butt ugly. But that's most probably just the OS X style and decorations. I can imagine it looking just fine on a prettier desktop.

Looks useful...

Posted Mar 11, 2013 17:04 UTC (Mon) by drag (guest, #31333) [Link]

It's not. I tried out several SIP clients for VoIP yesterday and Jitsi was one of them. It takes very long to start up and it's ugly. Neither of those things really bother me.

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.

Looks useful...

Posted Mar 11, 2013 17:41 UTC (Mon) by dashesy (guest, #74652) [Link]

Aesthetics aside, it should blend in. I think that is what makes it look good, or not. Unless all applications on OSX use X11 style, I would call the ones that do ugly, and similarly I call the stupid iTune on Windows butt ugly, or almost all Java GUI applications (well I like Eclipse). One more reason to use Qt for the GUI, then by default it blends in the native OS (although one can usually select other styles on command line)

Looks useful...

Posted Mar 11, 2013 16:22 UTC (Mon) by shmerl (guest, #65921) [Link]

Yep, I agree - they should remake the whole thing in C++/Qt.

Looks useful...

Posted Mar 11, 2013 19:42 UTC (Mon) by drag (guest, #31333) [Link]

In other words, you think they should just give up completely and start over from scratch.

Looks useful...

Posted Mar 12, 2013 21:01 UTC (Tue) by daniel (subscriber, #3181) [Link]

Translating a big project from Java to C++ hardly counts as starting over from scratch. For what it's worth, it's generally easier than going the other way.

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.

Looks useful...

Posted Mar 13, 2013 11:10 UTC (Wed) by drag (guest, #31333) [Link]

> Translating a big project from Java to C++ hardly counts as starting over from scratch. For what it's worth, it's generally easier than going the other way.

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.

Looks useful...

Posted Mar 13, 2013 12:09 UTC (Wed) by HelloWorld (guest, #56129) [Link]

Using a language that isn't memory-safe for an application that will face the internet is madness. It's a good thing the Jitsi developers didn't.

Looks useful...

Posted Mar 13, 2013 13:54 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> Using a language that isn't memory-safe for an application that will face the internet is madness.

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…

Looks useful...

Posted Mar 13, 2013 17:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Oh, no! Let's rewrite the kernel then.
A good idea. Microsoft is looking in that direction (see: Singularity, Midori).

Of course, right now it's not (yet) feasible because of the sheer size and complexity of Linux.

Looks useful...

Posted Mar 16, 2013 1:10 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> Oh, no! Let's rewrite the kernel then.
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...

Posted Mar 13, 2013 17:33 UTC (Wed) by codewiz (subscriber, #63050) [Link]

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

Looks useful...

Posted Mar 16, 2013 0:58 UTC (Sat) by HelloWorld (guest, #56129) [Link]

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

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


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds