Re: default messaging/VoIP client for Debian 8/Jessie
On 30/03/14 16:09, Thomas Goirand wrote:
> On 03/30/2014 06:55 PM, Matthias Urlichs wrote:
>> Thomas Goirand:
>>> P.S: I don't really care which client is the default, because I find the
>>> concept of default app bad in itself, and I think users should be given
>>> the choice, and it isn't the role of a distribution to choose for its
>>> users. However, if we *have* to have a default, probably Jitsi is a good
>> Most new users don't know enough to choose.
> Excuse me to say it this way, but ... NO!
Actually, many users will use what their friends are using, that's how
they end up using solutions like WhatsApp that uses their phone's IMEI
number as a password for XMPP.
We should make it easy for people to choose - and Debian does a great
job of that. But we should have a good default too.
The default needs to work for the widest number of use cases.
> My point above was only that I don't think it's a good idea to install
> so many stuff by default. It bloats the installer and make it difficult
> to fit on the 700 MB of the CD1. I very much prefer a more minimalistic
That is a different issue. If it is too much for a single CD
a) lets have it on DVD1
b) lets have some way to get stuff like this automatically if the user
supplements CD1 with a network mirror
c) or maybe we can have different CD sets, e.g. a set of disks for
"deskop / end user" and a different set of disks for "developer / sysadmin"
> Empathy isn't only doing VoIP, it does lots of other (chat) protocol,
> and trying to compare it to Jitsi doesn't help IMO. I myself prefer
Jitsi does IM/chat too, I just didn't emphasize that so mcuh.
> pidgin + Ekiga than just Empathy (and I find Jitsi too heavy and slow),
> but that's just me. Ask 5 persons, and probably you will get 5 different
> answers (including Ekiga, Skype, Linphone, Mumble, you-name-it). So why
> even bothering installing anything by default? In the case of Empathy,
> my understanding was that the reason it was there, is because it's
> designed to integrate with Gnome. I don't think we can say the same
> thing with Jitsi (which integrates with nothing).
Quite simply, when talking about a communications tool, I feel the
default option needs to be able to communicate with the widest number of
Jitsi currently does that - despite all the legitimate concerns about
disk space, GNOME UI, Java, whatever. It maximizes the number of people
who can contact each other.
By enabling the widest number of people to inter-operate, we help create
the foundation for a world of free VoIP. Solutions like Empathy can
grow into that at their own pace and the developers will have more
motivation to fill those gaps (like DTLS-SRTP support) when there is a
more active body of users to tap into.
In any case, please feel free to add the other options into the wiki:
> I also find it a pain to add the Jitsi dependencies in the default setup:
> Depends: libjitsi-jni (>= 2.4.4997-1), default-jre | java6-runtime,
> libunixsocket-java, libhttpcore-java, liblog4j1.2-java, libjmdns-java,
> libdnsjava-java, libmac-widgets-java, libfelix-main-java,
> libfelix-framework-java, libhttpclient-java, libhttpmime-java,
> libcommons-logging-java, libcommons-codec-java, libcommons-lang3-java,
> liblaf-widget-java, libdbus-java, libxpp3-java, libjzlib-java,
> libbcprov-java, libjna-java, libjgoodies-forms-java,
> libjson-simple-java, libjcalendar-java
> And yes, Java sux! :/ And it's going to take *a lot* of space on the
> CD1. This should therefore be discussed on the debian-cd list as well. I
> don't think that only the argument "it's better because of this or that
> feature" would be the only one (unfortunately).
I don't work exclusively with Java myself and I'm well aware of the
benefits and disadvantages.
Quite simply, it gives us a DFSG-compliant solution now. Thanks to
Java, it brings that solution to people who are not even ready to change
their whole OS and they can communicate with people who are 100%
Whatever you think about Java, it is free software and people are
welcome to develop alternatives. Some of the building blocks are
already out there in C or C++, like the reSIProcate project (which
includes reTurn for TURN and reflow for RTP media now).