[X2Go-Dev] X2Go KDrive

Fri Dec 21 15:37:20 CET 2018

Am 21.12.18 um 13:46 schrieb Ulrich Sibiller:
> On Fri, Dec 21, 2018 at 1:13 PM Oleksandr Shneyder
> <o.shneyder at 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 at 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

Amtsgericht München       | http://www.phoca-gmbh.de
HRB 196 658               | http://www.x2go.org
USt-IdNr.: DE281977973
-----------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20181221/26bdcd9f/attachment.sig>