NX Compression Technology To Go Closed Source 286
An anonymous reader writes "NoMachine has sneakily revealed it is closing its source of the NX compression technology with NX 4.0: 'This release marks an important milestone in the history of the company. Version 4.0 of the software, in fact, will be only available under a closed source license.'"
violating software patents? (Score:2, Interesting)
Who's had sucess? (Score:4, Interesting)
Re:NX is a bandaid (Score:5, Interesting)
It should be possible to make Wayland "network transparent". This would be the job of the "compositor". The Compositor takes the window images and assembles them into the screen display, and also takes user interface events and sends them to the programs. There is no reason it cannot assemble a window onto a remote display by talking to the Compositor running there, and return input events from that remote display. It can take hints about what areas of the windows were updated and doing comparisons and data compression so the images are sent quickly.
This is how Microsoft does remove windowing and it works reasonably well. Also how VNC works though they don't have access to the low levels similar to the Compositor.
Re:violating software patents? (Score:5, Interesting)
One of the antecedents of NX was a thing called "dxpc", which I used to use. It did compression, but more performance came from simply being a proxy and short-circuiting many of the round-trip communications X did. X is a very chatty protocol, and much of that chatter can be intelligently done away with. That's one of the things that dxpc, and now NX did.
A year or two back I found dxpc source, dusted it off, and it actually built cleanly. But it didn't work worth spit. I guess X has moved on.
Re:Buried in tl;dr (Score:4, Interesting)
Re:Nobody gives a shit. (Score:5, Interesting)
VNC opens a window that everything else goes in.
Running shit via "ssh -X [-Y]" makes anything I run integrate seamlessly into my environment.
Big difference, that.
Re:The more reason to use something else. (Score:5, Interesting)
I've never seen NX perform as well as VNC - espescially Turbo/Tiger VNC with VirtualGL.
If you're doing remote 3D/scientific visualization, Turbo/Tiger VNC and VirtualGL is far and away better than NX. I've gotten 20 fps for 1280x1024 3D graphics -- over a 2 Mbit connection. VirtualGL/TurboVNC can also handle clusters of GPU's (ie. many nodes, each rendering part of an extremely complex image). The final screen buffer is then tunneled over SSH. It's amazing, frankly, to have some-odd 16 or so GPU's rendering a hellaciously complex 3D scene, and then it gets sent over a tiny pipe using TurboVNC & VirtualGL, and is then displayed on a netbook with very usable frame rates.
I didn't believe it was possible until I tried it myself. Recall you can stream a movie at close to DVD quality at 2 MBit; so I guess it's not that unbelieveable after all.
NX, in comparison, couldn't even start glxgears.
you don't need any special ports open, just SSH
SSH is all you need for anything. It's port forwarding and tunneling capabilities can be used for anything that uses TCP/IP - NFS, VNC, Samba, HTTP, video games - anything.
NX does the same thing - it uses SSH port forwarding & tunneling; it just handles it transparently for the user.
This is hardly unique to NX, as many VNC implementations also uses SSH transparently for the user.
And it's been pointed out - there isn't a major platform that VNC doesn't support.
Re:violating software patents? (Score:4, Interesting)
Indeed, usually, the slowness in X is caused by network latency (the exception being if you are rendering a lot of pixels, e.g. for movies). Moreover, the slowness is often not inherent in the X protocol, but rather caused by how an application uses it. Some X clients are amazingly fast, even over moderate latency links.
This is also why you often get a more responsive UI by using something that just pushes pixel data, like VNC, instead of X. They work faster, even though they are less efficient in terms of amount of network traffic. It's not the throughput, it's the latency.
You could actually do the same thing with X: just render your whole app to an XImage, then render that to the server. This will be faster than synchronously performing all your drawing operations over the network, if you do lots of drawing operations. On the other hand, if you have lots of images that you tend to reuse, store them on the server as XPixmaps, and then you can render them faster than you could by pushing the pixels each time. X offers you this choice, and when used well, can actually be _faster_ than other technologies over any kind of network. The only thing I haven't found is a way to compress pixel data, but perhaps that is just because I haven't looked hard enough.