[X2go-dev] [Pkg-x2go-devel] Getting things started with x2goclient

[Erik Auerswald]

Hi,

On Wed, Feb 02, 2011 at 01:27:51PM -0500, Gerry Reno wrote:
> On 02/02/2011 12:12 PM, Gerry Reno wrote:
> > On 02/02/2011 12:04 PM, John A. Sullivan III wrote:
> >> On Wed, 2011-02-02 at 10:02 +0100, Erik Auerswald wrote:
> >>     
> >>> The problem with NoMachine going closed source is that the people
> >>> updating, improving and fixing (the free) NX will stop doing so (or
> >>> have already done that). NX is the enabler for X2Go, but I don't see
> >>> X2Go having the manpower to tackle the additional task of developing
> >>> resp. maintaining NX themselves.
> >>>       
> >> This concerns us quite a bit.  On the other hand, it plays to one of
> >> X2Go's strengths.  Heinz and Alex have always maintained that it is not
> >> a remote protocol solution like NoMachine but a complete Terminal Server
> >> Project.  Some have criticized it for just being a bunch of wrappers but
> >> I see that as its saving grace here.

'A bunch of wrappers' is something good.
http://www.catb.org/~esr/writings/taoup/html/ten-thousand.html ;-)

> >>  I'd imagine there is no reason why
> >> something else besides NX could not be slotted into the wrappers in
> >> place of NX -- perhaps something that handled video and other large
> >> screen updates better.

This has been the biggest selling point of NX technology. The next best
thing is said to be RDP, then come the more advanced VNC based projects.
YMMV.

> >> Of course, the big question is what.  HP has done some very interesting
> >> work with adaptive protocols, i.e., they adapt their compression
> >> algorithms to the needs of the video transfer.  If I understand them
> >> correctly, they handle the streaming video problem not by spooling the
> >> file to the physical desktop and playing it locally like Citrix does but
> >> by adapting the algorithms used for transmitting the video.  I do not
> >> believe they have open sourced the code.
> >>
> >> Almost two years ago, Heinz forwarded me a link to a University project
> >> that was investigating more video friendly remote video protocols.
> >>
> >> So, I don't have an answer but I think we can keep our eyes open for
> >> something besides NX.  Just an ignorant thought - John
> >>     
> > John, yes I've also been keeping my eye on some things like this.
> >
> > There are a number of efforts cropping up that are trying to take
> > advantage of GPU hardware on the client. 
> >
> > Wayland by Ubuntu is one that comes to mind. 
> >
> > The idea is to just send the screen "damage" events down to the client
> > and let the client GPU hardware handle it.
> 
> And just to follow up on this, it cannot be forgotten that network
> transparency has been a big part of the Unix/Linux experience is has
> been available for so long that it is now taken for granted.
> 
> Wayland and the other display technologies that people are working on
> are more structured around gaming and that "smooth and fast" experience
> while ignoring the network transparency part of the Unix/Linux display
> world.
> 
> It may be that we end up with a dual display technology approach.  X and
> "gamer GPU" technologies.

AFAIK Wayland is not planned to be network transparent, the general idea is
to use some existing remote access technology instead of network
transparent X, e.g. NX, VNC, or RDP. Alternatively even plain old X (with
its network transparency) as Wayland client.

Network transparency of X is seen as some legacy baggage not needed any
more.

I see this totally different, typing this mail from a semi-classic X
terminal with login to a multi user server via XDMCP...

One promising development is SPICE http://spice-space.org/ resp.
http://www.redhat.com/virtualization/rhev/desktop/spice/ .

Another new development (though the FAQ says it's only tested on high
bandwidth links) is xpra http://code.google.com/p/partiwm/wiki/xpra .
There is even a GUI app around it, winswitch http://winswitch.org/ .

What I tried with some kind of success across an analog modem link years ago
was the Differential X Protocoll Compressor (dxpc)
http://www.vigor.nu/dxpc/ .

Anyway, the first step to change some module in X2Go is to have a really
modular X2Go system. Changing imported libs to upstream / systems versions
is one step in that direction. Submitting changes upstream is part of this
process.

Which of the thousands of X2Go lists are we on currently? Is this on-topic?
I doubt that. ;-)

Erik
-- 
Dipl.-Inform. Erik Auerswald                http://www.fg-networking.de/
auerswald at fg-networking.de Tel: +49-631-4149988-0 Fax: +49-631-4149988-9

Gesellschaft für Fundamental Generic Networking mbH
Geschäftsführung: Volker Bauer, Jörg Mayer
Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630