Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Posted Mar 11, 2013 10:13 UTC (Mon) by njwhite (subscriber, #51848)
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)
Posted Mar 11, 2013 17:04 UTC (Mon) by drag (subscriber, #31333)
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 (subscriber, #74652)
Posted Mar 11, 2013 16:22 UTC (Mon) by shmerl (guest, #65921)
Posted Mar 11, 2013 19:42 UTC (Mon) by drag (subscriber, #31333)
Posted Mar 12, 2013 21:01 UTC (Tue) by daniel (subscriber, #3181)
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 (subscriber, #31333)
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 (subscriber, #56129)
Posted Mar 13, 2013 13:54 UTC (Wed) by mathstuf (subscriber, #69389)
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)
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 (subscriber, #56129)
Posted Mar 13, 2013 17:33 UTC (Wed) by codewiz (subscriber, #63050)
> 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 (subscriber, #56129)
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 © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds