I think that a lot of people are stopped from adopting Mumble because of the requirements for the server.
I'm talking about the dependencies on QT (And therefor X). I don't think a lot of dedicated servers have these libraries, and many do not have the access, or don't want to install them.
out of curiosity i just checked on our server if i could build the server.
I checked 15 machines running various fedora releases, centos 4 + 5.
None of the machines was able to build the server.
I asked the admin guys, if they could install qt4-devel on at least one of the machines.
The short answer: "No" (you don't want to hear the long ;-) )
I don't think i am the only one with this problem.
Sure statically linked packages or a build option to generate statically linked binaries would could ease this. I am totally confident you will come up with a nice way to do this for v2.0 ;-)
statically linking murmur should be as easy as 'qmake "CONFIG+=static"' and letting QTDIR and PATH point to a statically linked Qt.
I know that it's hard or next to impossible to get a recent QtCore library installed on a server. I'm currently facing the same problem on my own server (building Qt on this Dual P3 450 is out of question) but it can be easily "fixed" by using a static binary.
If I get this static build-system set up on my workstation I may even be able to provide snapshots of murmur, similar to the win32-client ones built by slicer :)
What's wrong with the static build?
Murmur requires Qt4 CORE which does NOT depend on X. Have a look at the ubuntu packages for an example.
@ccfreak2k: There doesn't seem to be a static amd64 build.
I have to agree with Phenax. Personally, I had a hard time deciding to adopt murmur on my Debian etch amd64 server.
Please consider this, guys:
When on a server running a system which does not provide a murmur package, you really have to love mumble to use it over the long-standing closed-source alternatives: If you can't find a suitable machine to do a static build, you have to install the Qt4 development package (which I did exclusively for murmur because I know it's excellent). For distributions which DON'T provide separate development packages for non-GUI Qt (in fact I do not know a single distribution that does, not even Gentoo!), this pulls in all kinds of esoteric X11 stuff you don't need for anything else (even if you only want to link against sql, network and core). (Which would of course mean that you'd have to install a C++ compiler in the first place.) Of couse, you could put yourself through building Qt yourself and reducing it to the non-GUI parts, but that's not what a whole lot of people would be willing to do...
The fact of the matter is:
Do you RE-HE-HE-ALLY have to use Qt for the server which is just handling the network? I bent over and installed all those libs, but the moment there's an open source alternative that offers similar features without Qt, I'm up and away. After all, even in 2007, memory isn't free. I am a developer myself, and I know that warm cozy feeling that Qt gives you, but for the sake of ease of deployment, IMHO you should consider removing the Qt dependency from murmur. Heck, if I was 10 years younger I would already have forked it. It would be C, and it wouldn't depend on anything.
For the client, you couldn't possibly have made a better choice of course. Qt rocks when applied in the right places.
The i386 build runs perfectly on x86_64.
Lenny already includes Qt4 and has it split into multiple packages. As does Ubuntu Gutsy. And the new Fedora.
Meaning that by the time our 1.1 release is out, this really is a non-issue, as long as you accept running binaries somebody else compiled.
And, without Qt, I'd need to code up a platform-independent network library myself. And thread abstraction. Oh, and databases, with multiple drivers. And configuration file reading. And DBus support. And I'd also loose the benefits of sharing the message marshalling code between the client and server.
In short, without Qt on the server, murmur would be 4-5 times as large, and I would spend much more time debugging the "dependency code" than I would adding new features. Murmur would also be considerably more crash-prone, as I wouldn't be able to do the same extended testing for e.g. network support on Win32 that has been done with Qt.
Maybe this is a litle bit off- topic, and /or reason for some laughter, but when I came along mumble, and figured out how small the binaries were, one of my first ideas was to install a mumur server on my router.
Don´t get me wrong, I´m not talking about a regular PC using AMD or Intel, I´m talking about my DSL- router, which is based on a Texas Instruments ARM7 processor @ 212 Mhz, 8Mb flash and 32 Mb RAM, running linux...
*time to start laughing..
Ok, I am aware, that this might be to little (flash) memory, to store the database, but since the router provides a USB port, and mem- sticks can easily be mounted into the filesystem...
Plus, I don´t want to have a huge amount of users, just some 5 guys over all.
Of course, this is far from being realistic, as long, as I need Qt, too, but since the only info on server requirements available is "should run on anything you can run Qt on", a 486 DX 33 could already be sufficient...
If there are some comments, exceeding "Now, that was a good one...!", go ahead.
Yeah, I got the static binary working fine.. no biggie.