[X2Go-Dev] X2Go KDrive

Ulrich Sibiller uli42 at gmx.de
Fri Dec 21 15:47:38 CET 2018


On Fri, Dec 21, 2018 at 3:37 PM Oleksandr Shneyder
<o.shneyder at phoca-gmbh.de> wrote:
>
> 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.

Understood.

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

Ok, you are talking about the the whole xorg release which is pretty
much irrelevant  since all the packages have their own version number
and are released independently.

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

Well, you could reconnect to the nxagent from elsewhere and profit
from the nx compressions but that's a very special usecase.

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

Well, I am using FF daily and it is very usable over NX. The only
things that are problematic are video and OpenGL.
There are some tunables in Firefox that really help (enable xrender,
disable smooth scrolling). For LAN-only you can also disable image
compression in NX.

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

Well, Nomachine nowadays claims to be the fastest solution, so at
least you have something to compete against ;-)

Uli


More information about the x2go-dev mailing list