I think all of the comments are good points regarding NoMachine's going closed source but I believe that precedence is that if you have historically provided the code under GPL you have already given those that use that software the perpetual right to continue using... just don't expect the originator (re NoMachine in this case) to fix bugs, improve on it etc.
NoMachine also has their own issues to deal with as some of their software I have got to assume was implemented using GPL'd code or snippets thereof so they would have had to rewrite their own using someone with no knowledge of or access to the original code. That is probably just one reason why the new version took so long as its nearly 18 months overdue.
Someone in the thread did mention that if NoMachine continued with some of the 3.x NX code that was GPL'd they would have to contribute back to the 3.x source any changes they make.
But... all of the above may be nothing or just fodder for lawyers to make money arguing over.
I think it would be worthwhile to post the question on the NoMachine forum as a question and get their official answer as it is a legitimate question that they must have decided on when they went closed-source for the 4.x release of NX.
I'm probably the right person technically to ask the question or name what modules etc but perhaps someone on the list could and let us know their answer.
Just a thought.
Brian
Hi,
On Tue, Feb 01, 2011 at 03:54:54PM -0500, brian mullan wrote:
I think all of the comments are good points regarding NoMachine's going closed source but I believe that precedence is that if you have historically provided the code under GPL you have already given those that use that software the perpetual right to continue using... just don't expect the originator (re NoMachine in this case) to fix bugs, improve on it etc.
Right, if somebody grabbed a copy of that code (e.g. archive.org or your favourite distri). Then you are free to fork and maintain your own codebase. Of course this is a lot more work than just using an existing and active project.
You cannot later revoke the GPL from published code, but the original publisher has no obligation to continue publishing it (except source code for binary releases for a reasonable time).
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.
Erik
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@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
On Wed, Feb 02, 2011 at 10:02:00 (CET), 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.
I feel the same.
Having said this, I notice that there seem to be other projects that also rely on the NX libraries, TTBOMK: freenx, opennx and neatx. It might make sense to discuss the future of the 'free' NX technology with all interested parties.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
Hi,
On Wed, Feb 02, 2011 at 11:13:29AM +0100, Reinhard Tartler wrote:
On Wed, Feb 02, 2011 at 10:02:00 (CET), 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.
I feel the same.
Having said this, I notice that there seem to be other projects that also rely on the NX libraries, TTBOMK: freenx, opennx and neatx. It might make sense to discuss the future of the 'free' NX technology with all interested parties.
An additional project is TaciX (https://launchpad.net/tacix).
Erik
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@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
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.
Erik 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. I'd imagine there is no reason why something else besides NX could not be slotted into the wrappers in
On Wed, 2011-02-02 at 10:02 +0100, Erik Auerswald wrote: <snip> place of NX -- perhaps something that handled video and other large screen updates better.
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
On 02/02/2011 12:04 PM, John A. Sullivan III wrote:
On Wed, 2011-02-02 at 10:02 +0100, Erik Auerswald wrote: <snip>
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.
Erik
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. 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.
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.
Regards, Gerry
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: <snip>
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.
Erik
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. 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.
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.
Regards, Gerry
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.
Regards, Gerry
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@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
Hi Erik,
On Do 03 Feb 2011 10:42:17 CET Erik Auerswald wrote:
Which of the thousands of X2Go lists are we on currently? Is this on-topic? I doubt that. ;-)
As we not yet have an x2go-nx mailint list 8-) you are completely
on-topic!!! Thanks for your input!!!
Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Thu, 2011-02-03 at 10:42 +0100, Erik Auerswald wrote: <snip>
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.
Indeed, NX runs rings around RDP. However, it fails miserably playing remote video and consumes lots of CPU when doing large screen updates.
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. <snip> One promising development is SPICE http://spice-space.org/ resp. http://www.redhat.com/virtualization/rhev/desktop/spice/ .
We looked at SPICE very seriously and are big RedHat fans however, at last look, it was primarily a LAN protocol and did not work well on lower bandwidth, WAN links.
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/ . Just took a very quick look at this and it looks very interesting! Thanks for digging it out - John <snip>
On Thu, 2011-02-03 at 10:42 +0100, Erik Auerswald wrote: <snip>
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/ .
Just took a very quick look at this and it looks very interesting! Thanks for digging it out - John <snip> <snip> Had a chance to read a bit more and it looks quite nice. The only thing
On Thu, 2011-02-03 at 08:00 -0500, John A. Sullivan III wrote: that concerns me from their DESIGN document is this statement:
Image Compression
dxpc compresses images differently, depending upon their type:
For monochrome images with width-to-height ratios greater than 10 and heights less than or equal to 32, it transposes the images from row-major to column-major representation and applies a variant of the text-compression algorithm using 'h'-bit "characters," where 'h' is the image height. (Why would it do something so strange? Well... FrameMaker draws bitmapped text one line at a time, and this algorithm compresses the bitmapped text much more effectively than anything else I could come up with.)
For other monochrome images, it uses a variant of Group 4 FAX encoding.
For 8-bit color images, it uses a CharCache to hold previous pixel values and encodes them using technique 4.
For anything else, it sends the whole image, uncompressed.
I do not know how NX compresses images but it seemed like there were a wealth of settings (I know we found best results with 16m-png-jpeg) so this might be a big step backwards. I'll defer to those who know more than I - John
-
brian mullan -
Erik Auerswald -
Gerry Reno -
John A. Sullivan III -
Mike Gabriel -
Reinhard Tartler