[X2Go-Dev] X2Go KDrive

[Oleksandr Shneyder]

Hi Uli,

Am 20.12.18 um 19:54 schrieb Ulrich Sibiller:
> On Thu, Dec 20, 2018 at 3:40 PM Oleksandr Shneyder
> <o.shneyder at phoca-gmbh.de> wrote:
>>
>> Hi All,
>>
>> I'm glad to introduce you a new X2Go feature - X2Go KDrive.
>> X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on
>> the recent X.Org code and can run modern desktops and apps, like Gnome-3
>> and KDE-5. I uploaded some sources to our git repository. It's not a
>> release or even testing version, just kind of review at the moment. We
>> don't have any build system for it yet. However I wrote some
>> instructions, which could help you to build it.
>>
>> check our wiki page if you need more information:
>>
>> https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
> 
> Wow, I am astonished how tiny the code is compared to nxagent!
> 
> Can you tell us a bit more why you developed this? 


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
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 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
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
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.
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
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
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.


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/44c4226c/attachment.sig>