Am 21.12.18 um 13:46 schrieb Ulrich Sibiller:
On Fri, Dec 21, 2018 at 1:13 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
First target - we need to support modern desktops. At the moment, KDE-5 or GNOME-3 are not working with X2Go environment. I'm not talking about different hacks and workarounds. For the industry environments all of
This is what we want to achieve by updateing nxagetn step-by-step. Unfortunately resources are too scarce to getting this done quickly. I have an nx-libs repo that's par with xorg 1.4.2-
It will be great when it'll be done. And I'll be happy to see it as a part of X2Go. As I told, it's not about NX against X2Go KDrive, I don't want to replace NX in X2Go. It's another solution with another purpose.
them are not acceptable. I had a request from my customer to implement such support for X2Go (as they already have a huge X2Go infrastructure). Main target - SLES 12SP1 and OpenSUSE Leap 42.3 with SLE-Classic desktop (GNOME3) on stations with dual FULL HD screens over LAN. They tested many existing solutions, like spice, VNC, all kinds of commercial products including new NX. None of them was suitable for their needs. This why X2Go KDrive was developed.
I don't see why X2gokdrive is preferable over Xvnc or similar solutions. Please explain.
See above. I described the target of my customers. They didn't achieve it with any of solutions they are tested. X2Go KDrive is made for their purposes. I'm happy that this work can be also available for community as a part of X2Go project.
I mean, this drops the main advantages of NX vs VNC and RDP: efficient compression, low bandwidth support.
It's true, that the compression on the level of frame buffer can't be as efficient as a compression on the level of X-protocol for the legacy X apps. However, the trends in developing of desktop applications are clear - multi platform support and that means that they are not optimized to run under X-Server. The best example are modern browsers like Chrom(e|ium) or FF. Compression on the level of X-Protocol in this case is even less efficient than on the level of FB. And amount of such applications is growing. I was thinking about porting NX to X.Org 7, but
We are on X.Org 7, currently Xorg 7.3 (which is called Xorg-xserver 1.3).
https://www.x.org/wiki/Releases/7.7/
I just see, that the NX, like X itself has no future. NX is obsolete since long time. And port to X.Org 7 will be obsolete again very soon. First, when (if) Xorg 7.8 will be released. Or when first major Linux
Xorg is a 1.20 currently, what do you mean by Xorg 7.8?
https://www.x.org/wiki/Releases/7.8/
distribution will come without X-Server. Another huge disadvantage is a need to have an X-Server on the client. It's ok if the client is running on Linux. In all other cases it's huge pain in the ass and source of any possible troubles. And it makes impossible to create HTML5 client or native clients for mobile devices.
No, it is not impossible. You can simply use the approach you took and run nxagent against an Xserver like Xvnc or x2gokdrive _on the server side_ that forwards the image data to some client. That client can be anything including html5.
hackish, and you won't need NX in this scenario at all, you'll lose all it advantages.
I don't think it's correct to say, that this solution will drop the main advantages of NX. NX in X2Go is just the way to transfer display over the network. X2Go itself is more than that. X2Go Kdrive is not going to
I am not talking about x2go, I am talking about nx.
I'm talking about X2Go. It has absolutely nothing to do with NX. Once again, NX is great. I love it and I'll be happy to see the new version of it. But we are talking now about another protocol for another purpose.
kick NX out of X2Go. NX was great some time ago and is still very good in some cases. But it's not only NX, why people using X2Go. Normal users choosing it, because it's very easy to use. Companies taking it, because it's scalable and has a lot of features. Now we are going to give them one new feature more. If they want to use their fancy new desktops with X2go, they will be able to do it with the help of X2Go KDrive. If they want to connect to their home computers over slow networks or use legacy desktops and apps, they'll still be able to do it with the help of NX.
Is this usable outside a LAN?
Well, it worked fine for me when I was connecting from Ajaccio in Corsica to my KDE5 session in Nürnberg. On both sides normal "home" Internet. In Nürnberg 100MB, in Ajaccio 10MB and 2.4 GHz Wifi. i would
NX works over a 64k ISDN line. While you are right that your tested setup is pretty much standard today it is not necessary to waste bandwidth just because you can. (Just my opinion, there are people that will disagree).
I absolutely agree with you. Unfortunately most of the developers don't care. Yes, NX will work on 64k ISDN line. But will you be able to start in this session Google Chrome and scroll through planet.debian.org? I can tell you, you won't be very happy with result. Even with 1Mbit DSL it doesn't work very well. The times of XRender support in FF are over. Unfortunately.
say pretty usual setup. KDE5 worked fine, Internet browser worked better than over NX. I'll add more optimization in the future, I have some interesting ideas. But it's not my first priority at the moment.
To save some development effort you could try to include the image compression/caching from nx-libs.
I don't think so, NX-Libs are developed for X-protocol. I don't think they are suited very well for X2Go KDrive. Image compression itself is not a big deal. Caching as well. I made some researches and took a look on some protocols, like RFB. None of them made me really happy and I decided to develop frame processing from scratch.
Alright, but remember a lot of thinking and testing went into the existing protocols, so why re-invent the wheel?
It's true. Also true, that existing protocols are developed long time ago for different kind of applications. It doesn't mean, that we can't import some good features in X2Go KDrive from another protocols. But I want to have a protocol which is optimized for the modern applications. For sure I could just take XVNC-Server and frb protocol. But I also could take FreeNX long time ago instead of developing X2Go.
regards Alex
Uli
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder