Hi all,
I am having some doubts about the future of X2Go and seeking for answers. I saw mails mentioning nx3.6 which seems a bit strange to me given that the next version of nomachine's nx is 4.0. And that is what makes me wonder about the future of x2go: The main parts of x2go (nx-agent and assorted low-level libraries) seem to go closed-source, at least as far as I can tell from their licensing documents. So what happens to X2Go?
I love the work you guys did and do. Resuming sessions while changing desktop- geometry is real fun. Having responsive desktops over WAN where vnc just doesn't work, is real fun. Using locally attached usb-stick on the remote server is real fun. Which made me "force" my colleages switch from our old VNC-based setup to X2Go. Sadly the expirience suffered when we updated the nx- libs from 3.4 to 3.5: On WAN-connections its still usable but on LAN X2Go looses in speed and latency and responsiveness against VNC. Which my co- workers really hate. My hope was that next nx-libs might fix this. And they probably will, but not for us when there is a price-tag associated with it. So how to go on in our case? What is your future planning for X2Go? Do you have plans (and knowledge and manpower) to further develop the nx-libs on the open-source base? Do you have a promise from nomachine that the libs will go open-source again? Do you have plans to use a different x-protocol like vnc from tigervnc or turbovnc? (Combining the speed of tigervnc and the features of sessions and apps and storage-forwarding of x2go seems like a good idea to me currently.)
Thanks for your answers!
Have a nice weekend,
Arnold
- On 19.05.2012 09:55 PM, Arnold Krille wrote:
I am having some doubts about the future of X2Go and seeking for answers. I saw mails mentioning nx3.6 which seems a bit strange to me given that the next version of nomachine's nx is 4.0.
Wait, wait, sorry, that's all my fault. nx 3.6.0 was entirely my "imagination", I needed a version higher than 3.5.0 to show future versions (i.e. yet unreleased) and decided to bump it up to 3.6.0. I should have went for 42.23...
Again: don't take this seriously, it was just a made-up example without *any* real knowledge of nomachine nx version numbers!
Best regards,
Mihai
On Saturday 19 May 2012 22:13:39 Mihai Moldovan wrote:
- On 19.05.2012 09:55 PM, Arnold Krille wrote:
I am having some doubts about the future of X2Go and seeking for answers. I saw mails mentioning nx3.6 which seems a bit strange to me given that the next version of nomachine's nx is 4.0.
Wait, wait, sorry, that's all my fault. nx 3.6.0 was entirely my "imagination", I needed a version higher than 3.5.0 to show future versions (i.e. yet unreleased) and decided to bump it up to 3.6.0. I should have went for 42.23...
Again: don't take this seriously, it was just a made-up example without *any* real knowledge of nomachine nx version numbers!
I didn't take your 3.6 seriuosly, but combined with my co-workers complaints yesterday morning and my internet-reading yesterday evening and my thoughts this morning, it was the trigger for bringing my thoughts to a white canvas and send them to the public via mailing-list.
Have fun,
Arnold
Hi Arnold,
On Sa 19 Mai 2012 21:55:28 CEST Arnold Krille wrote:
I am having some doubts about the future of X2Go and seeking for answers. I saw mails mentioning nx3.6 which seems a bit strange to me given that the next version of nomachine's nx is 4.0. And that is what makes me wonder about the future of x2go: The main parts of x2go (nx-agent and assorted low-level libraries) seem to go closed-source, at least as far as I can tell from their licensing documents. So what happens to X2Go?
There has been a long discussion about the current NX 3.5 code base.
NX 3.5 is based on Xorg 6.9 (I think). Pretty old kind of an Xorg and
probably lacking quite a few security patches reported against Xorg
upstream. This is the main problem of NX. And: it will still be there
with NX 4.0, as NoMachine has not freshed up the Xorg base NX got
forked from (AFAIK, people may correct me here).
The above said is the reason why NX 3.5 (esp. the nxagent/x2goagent)
will not find its way into Debian currently.
X2Go can work with any X agent available but nothing scales as good as
NX. As we do not believe in capturing technologies like VNC or
RemoteFX/RDP when we aim at performance we still stick to NX as GUI
rendering techology. X2Go itself in code is very flexible. If anything
better than NX will appear on the market, we will utilize it.
Sadly the expirience suffered when we updated the nx- libs from 3.4 to 3.5: On WAN-connections its still usable but on LAN X2Go looses in speed and latency and responsiveness against VNC. Which my co- workers really hate.
Then there must be something wrong with your setup. X2Go works on UMTS
(even GPRS) networks as well as on local area network. Not sure what
you are experiencing, but I cannot confirm what you report.
My hope was that next nx-libs might fix this. And they probably will, but not for us when there is a price-tag associated with it.
I am not so sure if NX 4.0 has really improved the NX technology
itself. From what I heard the improvements are rather on the session
protocol, multi-media integration etc.
So how to go on in our case? What is your future planning for X2Go?
Use NX 3.5 for now. We have an alternative approach we currently
discuss but currently we lack man power for even playing with code
snippets.
Do you have plans (and knowledge and manpower) to further develop the nx-libs on the open-source base?
Knowledge: yes, man power: no. What is needed for NX is a
re-integration into Xorg HEAD development. If there was a funding that
would cover 1-2 persons over a couple of months then this could be
feasible, but still: a huge project.
Do you have a promise from nomachine that the libs will go open-source again?
No, there is no real communication between X2Go and NoMachine. Apart
from bug reporting and answering to our reports.
Do you have plans to use a different x-protocol like vnc from tigervnc or turbovnc? (Combining the speed of tigervnc and the features of sessions and apps and storage-forwarding of x2go seems like a good idea to me currently.)
VNC is not an X protocol. Neither does it meet our needs and
requirements for a smooth remote X desktop.
Thanks for your open questions, my answers are just mine. Other
developers may have different answers.
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...
Am 20.05.2012 14:37, Mike Gabriel schrieb:
Pretty old kind of an Xorg and probably lacking quite a few security patches reported against Xorg upstream.
The thing to remember here is, that this isn't such an issue, as the client side X-server should be up to date and the server side X-server runns with the same privileges as your average application. Therefore - for normal use cases - there no real advantage in attacking the server, as your rights can not really be extended. Reducing these rights might be an interesting approach to make x2go a bit safer with minimal effort, though.
Cheers Morty
Sadly the expirience suffered when we updated the nx- libs from 3.4 to 3.5: On WAN-connections its still usable but on LAN X2Go looses in speed and latency and responsiveness against VNC. Which my co- workers really hate.
Then there must be something wrong with your setup. X2Go works on UMTS
(even GPRS) networks as well as on local area network. Not sure what
you are experiencing, but I cannot confirm what you report. <snip> I cannot confirm that it is slower than VNC on a LAN but I can confirm
On Sun, 2012-05-20 at 14:37 +0200, Mike Gabriel wrote: <snip> that I have seen a dramatic increase in latency since the move to libssh. It still really feels like Nagle is enabled. I've not 100% ruled out that it is not something in my environment like packet loss on our connections but it doesn't feel like it. It feels exactly like packet coalescing as it is just the last bit of input that is badly delay - badly as in a second or so so very noticeable with serious production impact as it leads to dangerous mistakes while editing documents. I wonder if libssh does not have the ability to disable it.
As a side note, I'm also really missing the setting of the ToS bits since moving to libssh. We currently have no way to distinguish X2Go interactive traffic (key strokes and screens) from bulk traffic (file transfers and print jobs).
Thanks - John
Am 21.05.2012 13:53, schrieb John A. Sullivan III:
file transfers and print jobs
I don't know if it's feasible for you to do so, but it might be possible to open a second SSH port on your server and have another script connect to that port. Even on Windows, PuTTY has a command line tool that allows for that. If you're using an ssh agent (PuTTY has pageant.exe for that, which works nicely with X2Go) then the user doesn't even have to type the password twice.
-Stefan
On Monday 21 May 2012 07:53:53 John A. Sullivan III wrote:
On Sun, 2012-05-20 at 14:37 +0200, Mike Gabriel wrote: <snip>
Sadly the expirience suffered when we updated the nx- libs from 3.4 to 3.5: On WAN-connections its still usable but on LAN X2Go looses in speed and latency and responsiveness against VNC. Which my co- workers really hate.
Then there must be something wrong with your setup. X2Go works on UMTS (even GPRS) networks as well as on local area network. Not sure what you are experiencing, but I cannot confirm what you report.
As I said, with my very poor internet-connection it is much better then VNC to log into work. But on lan it feels slower. I did measure it with some X-tests and the results where the same for local, xdmcp and x2go.
I cannot confirm that it is slower than VNC on a LAN but I can confirm that I have seen a dramatic increase in latency since the move to libssh.
When users "feel" that something is slow, its not always the throughput. Your explaination actually makes much more sense. It probably is the latency. That would also explain why it doesn't improve when I change compression levels.
It still really feels like Nagle is enabled. I've not 100% ruled out that it is not something in my environment like packet loss on our connections but it doesn't feel like it. It feels exactly like packet coalescing as it is just the last bit of input that is badly delay - badly as in a second or so so very noticeable with serious production impact as it leads to dangerous mistakes while editing documents. I wonder if libssh does not have the ability to disable it.
So what to do with that? Is there a way to disable ssh for local lan connections?
Have fun,
Arnold
-
Arnold Krille -
John A. Sullivan III -
Mihai Moldovan -
Mike Gabriel -
Moritz Strübe -
Stefan Baur