The Debian community has recently started discussing the way to choose the real-time communications (RTC/VoIP) desktop client for Debian 8 (jessie) users.
Debian 7 (wheezy), like Fedora, ships GNOME as the default desktop and the GNOME Empathy client is installed by default with it. Simon McVittie, Empathy package maintainer has provided a comprehensive response to the main discussion points indicating that the Empathy project comes from an Instant Messaging (IM) background (it is extremely easy to setup and use for XMPP chat) but is not a strong candidate for voice and video.Just how to choose an RTC/VoIP client then?
One question that is not answered definitively is just who should choose the default RTC client. Some people have strongly argued that the maintainers of individual desktop meta-packages should choose as they see fit.
Personally, I don't agree with this viewpoint and it is easy to explain why.
Just imagine the maintainers of GNOME choose one RTC application and the maintainers of XFCE choose an alternative and these two RTC applications don't talk to each other. If a GNOME user wants to call an XFCE user, do they have to go to extra effort to get an extra package installed? Do they even have to change their desktop? For power users these questions seem trivial but for many of our friends and family who we would like to contact with free software, it is not amusing.
When the goal of the user is to communicate freely and if they are to remain free to choose any of the desktops then a higher-level choice of RTC client (or at least a set of protocols that all default clients must support) becomes essential.Snail mail to the rescue?
There are several friends and family I want to be able to call with free software. The only way I could make it accessible to them was to burn self-booting Debian Live desktop DVDs with an RTC client pre-configured.
Once again, as a power-user maybe I have the capability to do this - but is this an efficient way to overcome those nasty proprietary RTC clients, burning one DVD at a time and waiting for it to be delivered by snail mail?A billion browsers can't be wrong
WebRTC has been in the most recent stable releases of Firefox/Iceweasel and Chrome/Chromium for over a year now. Many users already have these browsers thanks to automatic updates. It is even working well on the mobile versions of these browsers.
In principle, WebRTC relies on existing technologies such as the use of RTP as a transport for media streams. For reasons of security and call quality, the WebRTC standard mandates the use of several more recent standards and existing RTC clients simply do not interoperate with WebRTC browsers.
It really is time for proponents of free software to decide if they want to sink or swim in this world of changing communications technology. Browsers will not dumb-down to support VoIP softphones that were never really finished in the first place.Comparing Empathy and Jitsi
There are several compelling RTC clients to choose from and several of them are now being compared on the Debian wiki. Only Jitsi stands out offering the features needed for a world with a billion WebRTC browser users.Feature Empathy WebRTC requirement? Comments Internet Connectivity Establishment (ICE) and TURN (relay) Only for gmail XMPP accounts, and maybe not for much longer For all XMPP users with any standards-based TURN server, soon for SIP too Mandatory Enables effective discovery of NAT/firewall issues and refusal to place a call when there is a risk of one-way-audio. Some legacy softphones support STUN, which is only a subset of ICE/TURN. AVPF X Mandatory Enables more rapid feedback about degrading network conditions, packet loss, etc to help variable bit rate codecs adapt and maximise call quality. Most legacy VoIP softphones support AVP rather than AVPF. DTLS-SRTP X Mandatory for Firefox, soon for Chrome too DTLS-based peer-to-peer encryption of the media streams. Most legacy softphones support no encryption at all, some support the original SRTP mechanism based on SDES keys exchanged in the signalling path. Opus audio codec X Strongly recommended. G.711 can also be used but does not perform well on low bandwidth/unreliable connections Opus is a variable bit rate codec the supercedes codecs like Speex, SILK, iLBC, GSM and CELT. It is the only advanced codec browsers are expected or likely to implement. Most of the legacy softphones support the earlier codec versions (such as GSM) and some are coded in such a way that they can't support any variable bit-rate codec at all.
Retrofitting legacy softphones with all of these features is no walk in the park. Some of them may be able to achieve compliance more easily by simply throwing away their existing media code and rebuilding on top of the WebRTC media stack used by the browsers
However, the Jitsi community have already proven that their code can handle all of these requirements by using their media processing libraries to power their JitMeet WebRTC video conferencing server
Several people have spoken out to say they want an RTC client that has good desktop integration (just like Empathy) but I'm yet to see any of them contribute any code to such an effort.
Is this type of desktop integration the ultimate priority and stubbornly non-negotiable though? Is it more an example of zealous idealism that may snuff out hope of bringing the optimum communications tools into the hands of users?
As for solving all the other problems facing free communications software, the Jitsi community have been at it for more than 10 years. Just have a look at their scorecard on Github to see what I mean. Jitsi lead developer Emil Ivov has a PhD in multimedia and is a regular participant in the IETF, taking on some of the toughest questions, like how to make a world with two protocols (SIP and XMPP) friendly for real users.A serious issue for all Linux distributions
Communications technology is one of the most pervasive applications and also one of the least forgiving.
Users have limited patience with phones that don't work, as the Australian Russell Crowe demonstrated in his infamous phone-throwing incident.
Maximizing the number of possible users is the key factor that makes networks fail or succeed. It is a knife that cuts both ways: as the free software community struggles with this issue, it undermines our credibility on other issues and makes it harder to bring free desktops to our friends, families and workplaces. Do we really want to see the rest of our work in these areas undermined, especially when there is at least one extremely viable option knocking at the door?
I have always thought that having flexible deadlines in MOOCs is important, despite not having used them too much. Until last night, that is.
The course in question is Stanford's Statistical Learning and they adopted a policy of letting the students complete all the assignments of the 10 week course until the last day of the course, in March 21. Then, they graciously extended the deadline to April 4.
Were it not for such an extension, I would not have completed the course. I sent them a message on the course forums this morning to thank them for this, as this, in my experience, is not so common with MOOCs.
I reproduce below the message that I posted on the forums:
Subject: Thank you also for the EXTENSION of the deadlines
Dear professors and staff,
I would like to thank you (of course) for the course, as many others have already. Despite not liking edX platform too much (preferring the UI of, say, Coursera), your course was an exception, interesting enough (and funny enough) that I sticked to it until the end.
But I would like to bring attention here to a point that many may not have appreciated (or, perhaps, not expressed as clearly as I thought that it deserved), namely, the extension of the deadlines (and a uniform deadline for all homeworks).
In particular, due to some unfortunate facts of my personal life, I could not work on the course at all in the past few weeks. In fact, I completed units 4, 5, 6, 7, 8, 9, and 10 in the last 3 or 4 days and submitted my last quiz a few hours before today's midnight (at my local time, UTC-0300), and I still got a passing grade(!).
Even with my desire to finish the course, this would not have been possible if you had not graciously allowed for the deadline extension. I am sure that I may not be alone here in appreciating this extension (even though I think that I may be many standard deviations from the mean, doing the homework and R programs of 7 weeks in only 4 days).
Thank you so very much for everything (including this extension!),
The big news for this version is that we included a new “apt” binary that combines the most commonly used commands from apt-get and apt-cache. The commands are the same as their apt-get/apt-cache counterparts but with slightly different configuration options.
Currently the apt binary supports the following commands:
- list: which is similar to dpkg list and can be used with flags like
--installed or --upgradable.
- search: works just like apt-cache search but sorted alphabetically.
- show: works like apt-cache show but hide some details that people are less likely to care about (like the hashes). The full record is still available via apt-cache show of course.
- update: just like the regular apt-get update with color output enabled.
- install,remove: adds progress output during the dpkg run.
- upgrade: the same as apt-get dist-upgrade –with-new-pkgs.
- full-upgrade: a more meaningful name for dist-upgrade.
- edit-sources: edit sources.list using $EDITOR.
You can enable/disable the install progress via:# echo 'Dpkg::Progress-Fancy "1"' > /etc/apt/apt.conf.d/99progressbar
If you have further suggestions or bugreport about APT, get in touch and most importantly, have fun!
This week, the DrupalCon Austin sessions have been posted, and I'm thrilled to have one of my session submissions (in the DevOps track) selected: DevOps for Humans: Ansible for Drupal Deployment Victory!.
The session will go over how Ansible can be used to realize faster, easier, and more successful Drupal deployments, as well as Ansible's ability to make sure that every environment is 'like production', so you don't ever have surprises when you deploy code to its final destination.