Hi Stefan,
On Mi 02 Mär 2011 13:55:03 CET Stefan Baur wrote:
I have been "playing" with x2go for a while and it looks very
promising - a worthy successor to Nomachine NX - though I am unsure
about a few things - maybe someone here on this list could provide
some information?
I will try to provide as much information as I have, primarily to take
workload off of Heinz and Alex (the other core developer). They will
definitely supplement aspects where and if needed.
- With the recent announcement of Nomachine going closed source,
what does the future of x2go look like?
I will not answer this question directly as I know from a phone call
(yesterday) that Heinz plans to post some information on future
development of X2go on this list. So stay tuned for this.
1a) As far as I understand, x2go uses parts of the GPL'ed Nomachine
code, which will remain available in its current state due to the
GPL, but will not be maintained by Nomachine any more. Are the x2go
developers willing - and able - to maintain this part of the code,
in case it requires maintenance and / or security patches?
As far as I currently know, X2go's code base for NX3 components will
become the upstream source for Debian packages in the very near
future. As far as I can tell, there has come up quite some man power
in the project that can handle XServer code (i.e. Phil supporting the
VcXsrv developer with bugfixes and debugging) as well as NX code (esp.
Alex). Lately, there has also been offer of support from people from
the university of Erlangen. More on that will be in Heinz mail -
probably already tonight.
1b) Or are you going to do a re-write of the Nomachine code currently in use?
Of course there is a collection of ideas on NX alternatives. However,
this indeed is a question of man power and competence. The main
improvement X2go will need is around video streaming (MPEG etc.,
Flash). So a rewrite should include that. But as far as I know, the
current strategy is to stay with NX3 (as I said: out of lack of man
power).
1c) FreeNX seems to be a dying project (correct me if I'm wrong),
since their lead developer Fabian Franz has left the project (or at
least became inactive) quite a while ago - There are no Debian
packages available any more, the latest Ubuntu packages are, umm,
"flaky", and there hasn't been a new upstream release from the
FreeNX team in a few years, unless I'm totally mistaken. From what I found out about x2go, the guy in the lead is Heinz-M.
Graesing, who is working full-time as a system administrator and
maintaining x2go purely in his spare time (again, correct me if I'm
wrong). I would hate to see x2go going the FreeNX route once
something happens to Heinz that leaves him unable to maintain the
project. So I was wondering if there is a sufficient amount of other
people backing the project that the loss of the lead developer (be
it due to increased workload at his day job, health issues, or
simply loss of interest) can be dealt with, should the situation
arise? If that isn't the case right now, I would like to suggest
making plans for it asap - the best time to install a fire escape
ladder is before the house has a chance to start burning. ;-)
Thanks for addressing this issue. We are currently trying to share the
work load on more than two shoulders. The two main shoulders are Heinz
and Alex (Oleksandr Shneyder), both living and working southern Germany.
The sharing looks like this:
o Project coordination (Heinz, Alex)
o Core upstream development (Heinz, Alex)
o Code (C++, Perl etc.) development heavily supported by Uni
Erlangen (Morty,
Reinhart, Alexander)
o XServer troubles -> Phil, John (THANKS)
o Git/Bugtracker -> Mike
o Python X2go API / PyHoca-GUI -> Mike (currently sponsored by LinDix NL)
o Debian packaging -> moves to Collab-Maint (Team: Jonas Smedegaard, Mike
Gabriel)
o Ubuntu packaging -> Uni Erlangen (Reinhart)
o other packaging?
The code base is currently put into a sustainable and managable form
(Git: git.x2go.org), the release management will be switched to a Git
based release management.
The server code is relatively easy to understand and maintain. It's
mostly build up from scripts that wrap around helper applications,
some of these helper apps are standard Linux apps (ssh, pulseaudio,
sftp sub-system), some are X2go specific (as currently a derivative of
nxagent, called x2goagent).
The x2goclient-qt however is a Qt4 client written in C++ (or C?). The
latest great change was a full rewrite to usage of libssh (as opposed
to calling ssh child processes). This work is mainly committed by
Heinz and Alex.
The NX code is also written in C (or C++?). For this you need C/C++
coding abilities and also an insight into XServer technology. Man
power is welcome here, AFAIK.
Quite recent is my Python implementation of an X2go client, called
PyHoca. PyHoca brings with it a Python X2go(Client) API, a pyhoca-cli
(command line client, mostly for demo purpose) and a pyhoca-gui
(wxPython systray icon, basically working menu-based like GNOME's
network manager).
There will also be a complete rewrite of the X2go administration
tools. In Zweibrücken on Debian Edu conference Heinz has presented a
first alpha version of these and as far as I know they have already
advanced quite a bit with the code (he said something like... it's
finished for testing...).
Another plan is to put the i18n files of all subprojects together into
one x2go-i18n project in Git. Thus, translators of the software will
just have one location for the whole project to look after.
- I read that Univention is using x2go for their desktop
virtualization (see
<http://wiki.univention.de/index.php?title=UCS_Desktop_Virtualization_Services>). Are they active supporters of x2go (i.e. donating money or manpower to the
project)? (I ask because I'm hoping that a company planning a large-scale
commerial deployment like Univention seems to be doing would have an
interest in the x2go project staying alive and expanding.)
This is interesting... I have been on Univention's partner summit in
Feb this year and they told me about those plans. As I know that they
are heavily Pythonian I talked to the main developer (his name was als
Stefan, I think) about a Python API being available for X2go and left
my contact details. I have heard from them again, so far...
Interesting indeed.
As far as I know Univention does not directly re-inject code into the
OSS community (also a lack of man power). They publish under AGPL,
though, but as an OSS upstream developer you have to pick the ideas
and fixes out of there tarballs (not public VCS as far as I know).
Thus, I estimate that they will actually fork X2go for the UCS server
and maintain there own X2go'ish system (just a guess).
Maybe, if there is someone from Univention listening to this list you
could write some of the strategies you follow concerning X2go.
- I heard of legal issues regarding the project name and some other
stuff. That was back in December. Since the project is still named
x2go, and Univention is openly using this name, I was wondering if
these issues have been resolved?
The current status on this has to be answered by Heinz.
- Browsing the list archive, I saw that you are planning to provide
packages for sid and wheezy via the official Debian repositories - I
understand that it is too late to add packages for squeeze to the
official Debian repositories, now that squeeze has been released,
but will you provide packages for squeeze via your own repository?
Currently it only shows packages for lenny (regarding Debian; I'm
aware that you are providing packages for other Debian-based Distros
as well).
You currently can install the lenny packages on ,,all'' .deb based
Debian and Ubuntu versions. Beginning with Squeeze there are some
complaints about missing LSB definitions in the x2goserver init
script, but that will also be fixed soon and you can ignore them.
And yes: the plan is to provide .deb packages for Debian squeeze and
also backports for Debian lenny if feasible in the project's repository.
Additionally, the Ubuntu packaging will soon be covered fully by Uni
Erlangen, but more on that will be readable in Heinz's mail within the
next days.
- I understand that you need some sort of full-screen application
(similar to xdm/kdm/gdm) when running in thin client mode, and that
this is why the current x2go client looks the way it looks, but I
would really like to see a client that doesn't take up as much
screen space, especially on Windows. Would it be possible to add an option for a "smaller" login window,
similar to the one used by the current NX client: Provide text entry fields for username and password, and a drop-down
list for the session name; when a session name is given on the
command line, only show username and password fields; when the
session file was stored with a password, directly start the login
process?
Have you taken a look at PyHoca-GUI? That could be an alternative for
you then...
deb http://packages.das-netzwerkteam.de/debian <codename> main
or
deb http://packages.das-netzwerkteam.de/ubuntu <codename> main
=>
$ apt-get update $ apt-get install pyhoca-gui
(The reason why I'm asking for this is that I see a use case where
x2go is used in rootless mode to allow access to single
applications, and the big fullscreen thingie is kind of annoying to
the users that are currently used to the NX client.)
I plan to write an embedded menu extension for PyHoca-GUI (client
retrieves a menu tree from the server and allows to start remote
rootless applications from the GUI's menu). Some similar setup
(rootless provision of remote applications) is the current SAS
strategy of the PyHoca-GUI's main sponsor (Dick Kniep from LinDix in
the Netherlands).
Regarding question 5, I cannot provide patches myself, as I am not a
coder, but I would be willing to make a financial contribution
either to the x2go project, if it is possible for them to accept
such contributions, or to the coder providing the necessary patches
(as long as the price quote seems reasonable and affordable to me) -
if that helps motivate you to code. ;-)
So far, there has been a donation model for X2go. In several private
talks with Heinz I have suggested moving this donation model to a much
clearer contracting model. If you want a feature and if it is generic
enough for the X2go community, then you can contract Heinz, Alex, Mike
(Python) and in the future possibly others. If the feature is not
generic enough it is still possible to contract people, but the code
will not be merged into X2go mainstream projects (which should,
however, be the focus of contracting code developers).
I can definitely only speak for me at this point, and my disposition
is: if you need features for the Python X2go API or PyHoca-GUI then
you can of course contract me for that.
- Is there any way to get sound working (especially in rootless
mode, say, for Flash-based websites displayed in a remote
Firefox/Iceweasel window) with Debian lenny or squeeze on the server
side, and Windows on the client side? I've seen a few messages
concerning sound issues in the list archives, but I'm not sure if I
made a mistake during my test installation or if there is a general
problem and I can stop banging my head against the wall until the
developers declare that the issue is fixed.
This question has been answered by John already.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...