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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Tips for Optimizing Linux Memory Usage
- Secure Desktops with Qubes: Introduction
- Working with Command Arguments
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Fancy Tricks for Changing Numeric Base
- Secure Desktops with Qubes: Installation
- CentOS 6.8 Released
- Linux Mint 18
- The Italian Army Switches to LibreOffice
- Petros Koutoupis' RapidDisk
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide