The Arrival of NX, Part 1
This is the first in a seven-part series written by FreeNX Development Team member Kurt Pfeifle about his involvement with NX technology. Along the way, he gives some basic insight into the inner workings of NX and FreeNX while outlining its future roadmap. Much of what Kurt describes here can be reproduced and verified with one or two recent Knoppix CDs, version 3.6 or later. A working FreeNX Server setup and the NoMachine NX Client has been included in Knoppix now for over a year.
NX is a new technology that allows one to run remote X11 sessions across slow or low-bandwidth network connections. User experience with NX is one of excellent responsiveness. Users with previous remote X11 session experience are stunned by NX's speed and its snappy application interaction. Moreover, NX also can connect to remote RDP and VNC sessions and offer big performance wins over TightVNC and rdesktop remote access. NX can do all of this from Linux, Mac OS X, Solaris and Windows workstations as well as from some types of PDA gadgets.
Let's first get the yardstick defined. What do I mean by "slow link" or "narrow bandwidth"? People from some corners of the world think of a DSL link with a 384kb/sec connection as low-end connectivity. To them, slower links are not even worth considering. On my own horizon, low bandwidth means ISDN speed (64kbit/sec) down to even GXM modem speed (9.6kbit/sec or 9600bits/sec). A developer spoiled by fast links may not see a need to improve the performance of graphical applications running remotely. For him, X tends to be good enough. But not for me.
Plain vanilla remote X connections suck. I can't really work with them. I used to use them because there was no alternative. They still feel sluggish and unresponsive. Even across a 384kbit/sec DSL link, they are not much joy.
Ever since I saw how well ICA performed across an ISDN line for the Microsoft/Citrix Metaframe Server access, I envied their users. I wanted the same speed and responsiveness for remote X. But every expert I talked to told me, "It's impossible. See, Keith Packard tried it once. He started to create a Low Bandwidth X (LBX) protocol, but even he gave up. Read his farewell document, "LBX Postmortem", and you'll see it is impossible!"
So, I read Keith's conclusive proof, dated January 2001, about this impossible dream. I admit that I didn't grasp all of the technical details of his arguments. I am not a developer; I can't read and understand C or C++ source code, and I am not an X11 expert. I have to trust some third-party expertise or my own user experience with a certain piece of software.
Keith based his conclusions on measurements of real-life applications and real-life networks. He was able to accept even unflattering results--his own baby, LBX, failed to live up to expectations, including his own. LBX would never work better than SSH with ZLIB-compression, he concluded; and SSH with ZLIB-compression already was at everybody's fingertips. So his final recommendation was simply to use something like:
ssh -X -C username@remotehost start-my-X-application.command.sh
where ssh creates the connection and gives you encryption and security, -C gives the best compression you can get and -X forwards X11 output to your local X display.
If someone of Keith Packard's stature says that X network performance can't be improved considerably without drastic changes in the internals of applications, there is no hope, right? At this point, I played nice and gave up asking.
- Android Browser Security--What You Haven't Been Told
- Readers' Choice Awards 2013
- Epiq Solutions' Sidekiq M.2
- The Many Paths to a Solution
- Nativ Disc
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Synopsys' Coverity
- Securing the Programmer
- Downloading an Entire Web Site with wget
- Naztech's Roadstar 5 Car Charger
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide