Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Open Source Software IT

NX Compression Technology To Go Closed Source 286 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.'"
This discussion has been archived. No new comments can be posted.

NX Compression Technology To Go Closed Source

Comments Filter:
  • by MichaelKristopeit319 (1963200) on Tuesday December 21, 2010 @08:05PM (#34636050)
    why else would they close their source when the compression industry is already saturated with near optimal free products?
  • Who's had sucess? (Score:4, Interesting)

    by jvillain (546827) on Tuesday December 21, 2010 @08:26PM (#34636256)
    I am trying to think of any company that has closed their source and been more successful and I can't think of any. It sure didn't help SSH. NX used to be really great and a number of people I know used it. But I don't know any one that still does.
  • Re:NX is a bandaid (Score:5, Interesting)

    by spitzak (4019) on Tuesday December 21, 2010 @09:57PM (#34637006) Homepage

    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.

  • by dpilot (134227) on Tuesday December 21, 2010 @10:17PM (#34637138) Homepage Journal

    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)

    by timeOday (582209) on Wednesday December 22, 2010 @12:32AM (#34637892)
    I did it online once too, a few months ago. But last night I spent about 20 minutes searching the menus and searching for help, and I think they removed the function.
  • by X0563511 (793323) on Wednesday December 22, 2010 @12:35AM (#34637908) Homepage Journal

    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.

  • by sl3xd (111641) * on Wednesday December 22, 2010 @03:11AM (#34638688) Journal

    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.

  • by RAMMS+EIN (578166) on Wednesday December 22, 2010 @04:57AM (#34639058) Homepage Journal

    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.

Real programs don't eat cache.

Working...