posted by Tom Chance on Mon 30th Aug 2004 21:03 UTC

"NX, Page 2/3"

How does NX compare to methods used up to now?

Fabian Franz: What do you mean with "methods used up to now"? VNC? Citrix Metaframe? Remote Desktop? PC Anywhere? Tarantella?

In comparison to all of those, NX performes better while being cheaper. Additionally it is future-proof, since the source code is freely available. And it's much more flexible, since it covers several platforms.

Kurt Pfeifle: If you meant to compare FreeNX and NoMachine's NX product: The performance is not any different. On the other hand you won't get a support contract for FreeNX by us anytime soon. For that, you should contact NoMachine.

Or, if if you need a new client plattform (e.g. Symbian), you won't find it here. And if you need extended administration tools with graphical user interface or a web interface: Ask NoMachine. Or find a developer, who develops that kind of stuff for you...

NX was published by NoMachnine more than a year ago. But only with your presentation at LinuxTag, the technology became visible to the broad public. How is NoMachine involved in the KDE/Debian integration?

Fabian Franz: NoMachine totally supports our activities. Gian Filippo Pintari keeps us informed about planned NX protocol changes and keeps us aware of bugs in our implementation.

NoMachine values the compatibility between our Free and their commerical version just as much as we do. Users should be able to use the FreeNX/KDE client to connect to a commerical NX Server in the same way NoMachine NX clients from all operating systems should be able to access the KDE/Knoppix FreeNX server.

Kurt Pfeifle: NoMachine committed themselves to use the exactly same libraries for their commercial products as they are releasing under the GPL, not different or "improved" variants. In my opinion, this fundamentially distinguishes their business model from those of Codeweavers/WINE or artofcode/Ghostscript.

What possibilities arise for the developers from the implementation of NX?

Fabian Franz: Our implemementation was intentionally kept simple. It's a simple Bash script...

You are surprised? Yeah, right: FreeNX Server is a Bash script, which glues together GPL library and executable components of NX to a working whole. All that stuff existed for 15 months untouched.

The fact that it is Bash means that every Linux developer can fix errors in our FreeNX server. ;-)

Kurt Pfeifle: I was merely a mentor for the FreeNX development and I do the documentation. But I can confirm: Fabian isn't lying... ;-)

FreeNX consists of less than 500 lines of Bash code (additionally to the NoMachine/NX source code parts, which are under the GPL).

Fabian did the implementation of the FreeNX server all by himself. First of all, Fabian is a true Bash wizard.

Secondly, this implementation should prove how "complete" the GPL components of the NX are already since 15 months.

Third, it should prove all the sceptics among the FOSS developers wrong, who ignored NX and claimed a free NX implmentation would be "too difficult" without looking at all at the NX source.

And last but not least, we practially don't lose any speed by using shell scripts, since the primary work is done by the precompiled GPL/NX components.

Fabian Franz: Should I reveal a little secret? The first working version of FreeNX was the result of merely one night of programming and the source code was only 180 lines... ;-)

The GPL components of NX are really complete and not just a "crippled decoy", like many predicted prematurely after they looked on the NoMachine website, but not at the NX source code.

The Open Source community should really be thankful to NoMachine for this great gift!

Kurt Pfeifle: Developers can use NX and FreeNX for many occasions -- just like every end user. We hope that FreeNX will also attract developers for NX core development. There's a lot of amazing potential.

How is the data stream of an NX connection protected, especially when operating via open networks?

Kurt Pfeifle: Using SSH.

The connection initiation always uses SSH. No NX server can work without an SSH daemon. After authentican, you are free to decided wether you want encryption of not. Disabling session encrytion can help older CPUs on NX clients, but should only be used within self-contained and firewall-protected LANs.

Fabian Franz: An NX server installation is always as secrure as the respective SSH installation. NX does not run a seperate daemon on an own port but uses the ssh daemon for connections.

How can NX be used in large instllations with a high number of clients? Where are the limits?

Kurt Pfeifle: Every KDE fullscreen session takes about 40 kBit/sec of bandwith to work fluently. This of course allows using non-KDE applications inside the session too, like OpenOffice, Mozilla or Acrobat Reader.

Per running KDE user session, an NX server takes about 40MByte of RAM and 100Mhz of CPU. A current standard PC as sold today, with 1 GB of RAM and 3Ghz CPU should allow 25 sessions in parallel without any problems. It would probably get flanky at 35 parallel sessions.

Fabian Franz: Since NX is distributable among application servers on multiple node, one could imagine a blade center as offered by HP or IBM, to allow several hundreds of parallel sessions.

Anyway, a NX application server busts the borders where a Citrix MetaFrame server prostrates.

Table of contents
  1. "NX, Page 1/3"
  2. "NX, Page 2/3"
  3. "NX, Page 3/3"
e p (0)    74 Comment(s)

Technology White Papers

See More