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.'"
New? (Score:5, Informative)
Perhaps I don't remember it right, but in my recollection, NoMachine has always been a bit possessive with their (definitely impressive) technology. To the point that lesser alternatives have continued to be used and even developed.
Missing explanatory link in summary (Score:5, Informative)
Here is an explanation of what NX compression technology is [wikipedia.org].
Re:New? (Score:5, Informative)
Well, they previously opened under an "open source it but make the open-source version a pain-in-the-ass to use" business model. You got a random code dump that wasn't even buildable. However, there was code there, and it was possible to fix it up, which is what the FreeNX and OpenNX projects did (along with adding a few things). With no GPL release of the core libraries, it's no longer possible to even use it as a base for a cleaned-up open-source release--- either projects will have to independently develop a fork of the previous version, or come up with something else.
Re:Fast remote X connection... (Score:5, Informative)
I am a real CLI addict, but some things still require a GUI.
For example comparing a server's /etc tree with another one, and applying changes.I found Meld to be great for that. But to be able to effectively run Meld on an otherwise headless remote server, connected through a slow ADSL link, I need NX.
Plain X forwarding is fine on a LAN, but it's not really usable over ADSL.
Er... (Score:5, Informative)
The reason that the "core" bits of NX were always Free is because dxpc (and, thus, mlview-dxpc, from which NX sprang) is only available under the GPL.
If i was involved in dxpc (or mlview-dxpc, really, although I'd imagine most of those changes are owned by the NX folks) development I'd be lawyering up at this point, if only to get some kind of proof that I wasn't being ripped off.
Re:Who's had sucess? (Score:5, Informative)
SSH lives on as Tectia and still has quite the revenue stream selling to companies that presume it's more secure because they have to pay for it. Commercial SSH has always just pretty much been for suckers and continues to be, the open source aspect being pretty well a moot point.
Re:New? (Score:5, Informative)
I'm hoping this will be the impetus for the forks to abandon all pretense of interoperability with NoMachine's crap session management and do it right.
Re:The more reason to use something else. (Score:3, Informative)
Version 3 is in fact very good, but not perfect. It seems to have problems if the client is on a system with multiple monitors. Also, I have seen crashes when I full-screen SOC-Encounter. An update/bug fix would be very welcome.
This product is simply the BEST remote software for *NIX systems, period. VNC (all flavors) runs like an absolute dog compared to NX and, depending on the program, it as times completely unusable, while NX is generally very smooth.
Re:violating software patents? (Score:3, Informative)
uh... optimal is NOT subjective at all.
Wrong, douche bag.
There are at least 4 metrics in the case of data compression that can be optimized for, and further that any metric can have a weighted level of importance:
1) Compression ratio.
2) Speed of compression.
3) Memory Overhead (the good compressors use a LOT of memory.. one compression competition limits memory use to "only" 1 gigabyte)
4) Recovery rate from corruption/transmission errors.
You are obviously one of those compression noobs that talks the big talk but doesnt have any applied experience in the matter.
Re:violating software patents? (Score:4, Informative)
Re:Nobody gives a shit. (Score:5, Informative)
I was just using NX last night to connect to my Linux work machine from home. I've used VNC but my experience is that NX is much faster over my internet connection (20/8) than VNC was over a LAN, and this is running NX on Windows in a VM on my Linux box (because I've had some issues with the VPN in Linux).
NX is a lot more intelligent than VNC in that it caches a lot of stuff on the client side and is X aware. I.e. it keeps track of X bitmaps and will use jpeg compression on them when sending them across, renders fonts locally, etc. It is *MUCH* more responsive than running an X app remotely over ssh.
I've found NX to be quite usable even when the available bandwidth is fairly low whereas VNC would be useless. It actually seemed faster to run my web browser over NX rather than running it locally.
Sometimes I wish it could behave more like running a remote X application without having to bring up the entire desktop, but other than I'm a convert.
I've also seen a lot of VNC servers get borked where a VNC session suddenly starts gobbling up 100% of the CPU. I don't know if that's been fixed yet, but it was a major problem when I used it.
Re:The more reason to use something else. (Score:5, Informative)
Ouch. Getting your password transferred to & used at arbitrary locations is hardly more secure than the challenge/response PK schema in which your secrets never leave your computer.
IMO the reasons behind this are merely laziness/incompetence on top of bad design.
I am not. First of all it is un-secure to enter your password somewhere without really having control of where it goes.
Second, it is a pain in the ass. Even if you use PK for all your ssh access you will have to maintain a password just for nx sake. Come on in the year 2010 (or 2011 for that matter) it is totally idiotic to use ssh with passwords for normal daily jobs.
That's why NX made its way out of my door very shortly after trying it out.
If you want to know the whole story then read on.
What really happens with NX is that your client first opens a ssh session to nx@server - this session uses PK auth. Unfortunately the private key is well known, as it ships with a default one and almost noone bothers with replacing it (in fact it is not advised - lol). That means anyone in the world can open that connection to your server and get authenticated and proceed to step 2.
Coming to step 2 after logging to your server as user nx the nx server program is launched. This program actually manages translating the X window protocol to the nx protocol - all the "compression" and stuff. It will set up a DISPLAY variable to point to itself and then launches ANOTHER ssh to you@localhost (localhost being the server). That's where your password comes in.
After that X applications (usually the whole desktop) can be launched under your account, they are going to talk to the sshd spawned by ssh @localhost, where the X protocol is encrypted and compressed, shortly afterwards decompressed and decrypted by the nx server running the ssh command, then translated to nx protocol, encrypted and compressed again through the ssh session for user nx all the way to your client pc where finally decrypted, decompressed, translated to X and displayed on your screen.
As you can see the weird part here is the user nx running the nx server. It is technically absolutely possible to avoid at all this step. The nx server could be easily launched on behalf of the user with the applications spawned from there. IIRC the introduction of the nx account is something as ill as licensing.
Even with the nx account present it is totally irresponsible to leave it protected by well known PK, for the sake of making the installation & deployment 2 clicks easier. The impact is that anyone can launch a nx server on your server. They claim it is secure - hah. At the very least you can start brute forcing passwords for local users, at the other extreme you can find a neat hole to hijack the process and make your way in to the system. Combine with the knowledge of some kernel loophole and you can start scanning for nx enabled systems all over the internet with satisfaction guaranteed.
And even with the ssh@localhost weirdness it is feasible to use PK auth, either by use of ssh agent or some sort of channel forwarding. But no, that's not supported, because...
... enter the customized ssh client shipped with nx which one of the steps involves. Being customized it is never kept up to date so say goodbye to features and say welcome another lot of security holes.
And finally when I read the forums about the open source client wondering if all this mess was fixed at last, I found out that it wasn't/won't - for COMPATIBILITY reasons.
Sad story.
Re:The more reason to use something else. (Score:5, Informative)
I've gotten 20 fps for 1280x1024 3D graphics -- over a 2 Mbit connection.
On the other hand for usable browsing and general desktop sessions NX doesn't need close to 2Mbit, it works well for me at 56kbit. So it's horses for courses, I guess.
It's not the VNC protocol that gives you your good 3D performance, it's the architecture of VirtualGL. I don't think there's a good reason VirtualGL couldn't be made to work with NX as well as VNC.
The future probably belongs to SPICE [redhat.com], which redhat (a company who do know how to develop open source code) are creating for remote access to virtualised systems.