Cascade of problems

It is unbelievable how things can go bad starting from a small number of problems. This afternoon, I was overwhelmed by several hurdles, but there were only two main root causes: keyboard instability and network bandwith issue.

Everything started with the delivery of my new AZIO keyboard and Razer Taipan mouse. Well, these are low-risk plug-in devices that won’t disturb my work too much, so let’s plug them in and see how that goes. The mouse worked fine. It seems sturdy and scroll wheel is working well, far better than this Microsoft Comfort mouse I used  a while ago. Pointer moves smoothly and there are several extra buttons that could be useful. Sensitivity can be adjusted with the touch of a button, so it can be decreased for office work for the pointer to move at reasonable speed and increased in games like Fract where I had to move the mouse five meters away to manipulate some controls!

Keyboard, on the other hand, didn’t work too well. Keys are large and the LED backlight is very nice, but the keyboard has a tendency to skip keys when I type. It skips randomly, especially the e and the s. This is a real pain when trying to do anything other than looking at emails or analyzing code or data. I tried to give it some time, but the problem persisted, up to the point I got fed up and put back my old keyboard.

Some time after I put back the old keyboard, my NX connection to my company’s remote server dropped. I had to reconnect and then got the DPI bug again. The remote desktop was running in a low resolution as if DPI scaling wasn’t disabled for the NX client anymore. I tried to restart the client, checked the DPI setting, everything was fine. I had to reboot the whole system to get my resolution back at 1680×1050 in the remote desktop.

That worked for some time, then things became laggy. Ok, we need a plan B: a VirtualBox guest running Linux and accessing the files remotely using sshfs. I already had a VM on my home PC, so I wanted to copy it on my company’s ultrabook as a first step. That was intended to run in the background and not disturb anything, but file transfer became unstable and started to slow down and stop completely. I had to initiate file transfer from my home PC: it wouldn’t work the other way round, again because of Windows. File transfer from Ubuntu failed, because the VirtualBox image was on my Windows partition and Ubuntu refused to mount it because now, Windows 8 doesn’t unmount partitions correctly, so NTFS-3G will eventuall have to adapt and implement very patchy and ugly workaround against this!

That forced me to switch back and forth between the two PCs and I was having trouble finding the buttons to switch the KVM and the HDMI switch. I don’t have a large enough desk to put two displays, two keyboards and mice so I am stuck with that stupid KVM and HDMI switch.

Things came to a total dead end when the network connection of the ultrabook stopped completely. Windows was unable to interact with my router and thus connect to the Internet. All I could do is turn wi-fi back on. I turned it off this morning, because Windows was stubbornly trying to use wi-fi instead of wired Ethernet! It took a while for wi-fi to come up, it didn’t connect automatically to my router, it took a while to connect, and connection was limited.

If I remember well, I could connect back to my NX server, but everything hung up and I had to terminate the NX client. Nothing would work: no ALT-F4, no right-click+Close program, I had to use the task manager. Then any attempt to connect back to the server returned to hung up NX session. I would have had to find back a long and complicated command on company’s wiki to reset the X server. No way! Tired of all this, I rebooted the whole server instead.

I ended up copying my files locally to not use the remote server at all and transfer the VirtualBox image using an external hard drive. That counter-productive end of afternoon totally drained me out and I was quite exasperated and overwheled after that. I have been fighting for weeks against the NX Client and the grid infrastructure I was connecting to, without nothing other than patchy workarounds that sometimes apply, sometimes fail. I felt I reached the dead end at this point. I needed a solution.

But that was working fine during the morning. Why, all of a sudden, things went south? All started from network issues: the ultrabook preferred wi-fi over wired Ethernet, the network connection to my NX server dropped all of a sudden, file transfer was unstable, Windows couldn’t access the network anymore, etc. So let’s act on network first, before fixing NX client again! Maybe that USB network interface is flawky and I would have to try with a new one.

But first, let’s remove it from that USB hub and plug it in directly into the ultrabook. That hub worked for a while, when I was using network just for sparse file transfers, but higher bandwith is needed for a full remote desktop connection. It is still good for keyboard and mouse, and necessary since that ultrabook has just two USB ports!

So I tried this, and that seemed to help! Connection to wired Ethernet happened almost instantly, Windows didn’t fall back to wi-fi as this morning, and I worked for half an hour, remotely connected, without any issue. As a final test, I transferred an Ubuntu ISO over the network and that worked without a flaw.

That hub is capable of transferring only a theoretic 480Mbts/s. It is used to carry over information from small devices like keyboards, mice, occasional data transfer from  USB stick or external hard drive, but how about something requesting 100Mbits/s constantly? That may well overload the poor little hub.

If that still bugs, I will give a shot to the Gigabit Ethernet adapter I have in the office. If that one fails as well, I will probably have to give up on this utrabook and start carrying over the heavier laptop from office to home.


Issues with NoMachine’s NX Client

I recently tried using NoMachine‘s NX Client to connect to a virtual machine at work running NX Server, and got an incredible number of problems. At the end, I gave up on NX and fell back to VNC, but this exploration is nevertheless interesting.

The virtual machine at my work place is running NX Server 3.4.0-12, probably the free edition. I have no control over this. However, I can control on which NX client I run.

I got issues with the screen resolution on Windows 8, erratic keyboard responses and ended up switching to VNC after I couldn’t find any solution under Windows 8.

Awful screen resolution on Windows 8

When I was connecting to NX server using NX Client 3 or 4 using my main corporate laptop running Windows 7, I got no display problem. The desktop showed up in a nice 1674×954 resolution, which is near the native 1680×1050 I have with the 22″ LCD out there. I can bump up the resolution closer to native by switching my NX client to full screen.

However, I got a secondary ultrabook running Windows 8.1. Because it is lightweight, I like to use it when working from home. However, running NX client on this machine causes a major issue: display resolution goes down to 1114×634! I tried searching for a solution or at least a workaround to no avail. Nobody seems to be having this issue, and there is a very good reason why.

Because I am visually impaired, I need larger fonts and mouse pointer. There is a very neat way to get this under Windows since 7: the DPI scaling. It can be adjusted by right-clicking on the Desktop, accessing Personnalize and clicking on Display. I use to bump up the scaling to 150% which makes fonts large enough for most cases and also enlarges mouse pointer. This doesn’t completely remove the need for application-specific tweaking, but this at least helps greatly. Magnification is done without lowering screen resolution, by just applying a scaling before rendering the graphical elements, as opposed to scale bitmaps after the fact as the Windows built-in and third-party zooming applications do.

Under Windows 7, this functionality doesn’t affect NX client at all. It gets the display resolution and can make use of all pixels. Under Windows 8, it seems to get some form of virtual resolution sensitive to the scaling! Let’s do the math real quick. If we divide 1680 by 1.5, we get 1120. Dividing 1050 by 1.5 yields 700. Isn’t that near 1114×634?

This is the third application misbehaving with DPI scaling for me. First one has been Ableton’s Live virtual studio. Second one has been Corel’s VideoStudio, a video editor. In both cases, I was able to turn off DPI scaling locally for the offending application. This is easy for 32 bits applications: just right click on it, access the properties, then the compatibility tab, and there is a check box for this. For 64-bits applications, this is trickier and would deserve its own post since it involves registry hacking. But this is doable, because this is how I worked out Ableton’s Live. I have a post in French about this, called Le problème des caractères trop petits sous Windows.

However, this is miserably failing for NX Client. I tried applying the compatibility setting on each and every executable found in the installation directory, including NXWin.exe which is responsible for showing the desktop, NXSSH.exe which establishes the SSH connection, NXClient.exe which is the frontend offering the configuration panel, etc. I tried upgrading from NX Client 3 (recommended by my company since NX Server 3 is in use) to NX Client 4 with absolutely no change.

There is only ONE workaround I could find: completely disable, session-wide, the DPI scaling, decreasing it from 150% down to the regular 100%. However, I just cannot work efficiently this way. Although I can bump up font size individually for elements, the mouse pointer will remain desperately small, even when I use the Magnified pointer. I couldn’t find any convincing solution, although I got a couple of proposed ideas that I will list there for the sake of completeness.

  1. Start a Remote Desktop Connection from my ultrabook to my corporate laptop, or even from my home PC (that would free me completely from transporting a laptop between office and home). This is an attracting solution used by many colleagues. I tried it and it unfortunately failed because Virtuawin didn’t work at all on the remote desktop. Well, it worked, but with no keyboard shortcuts to switch between desktops! Some colleagues got past this by changing keys of Virtuawin. However, if I start the remote desktop connection while no session is active on the laptop, font sizes and mouse pointer are small as if there were no DPI scaling. I couldn’t find any solution for this second issue.
  2. Run NX client from my home computer instead of my company’s ultrabook. This machine is a dual-boot system with Ubuntu 14.04 and Windows 8.1. I could run NX Client from Ubuntu (version 4, because NX Client 3 for Linux is not available for free anymore on NoMachine’s web site and my company offers the binaries of NX Client 3 only for Windows and Mac), I managed to setup the VPN connection, so that is doable. However, I heard that the VPN connection is unstable under Linux. Yes, I could work around by establishing a SSH tunnel, letting my Windows ultrabook manage VPN and Linux manage NX. But connection to Microsoft’s Lync will cause difficulty, especially for voice chat. I will also have no option for Outlook other than using the web mail which lacks keyboard shortcuts, or switching back and forth like crazy between the ultrabook and the Linux box! Even with an ideal dual monitor setup, with one screen for the ultrabook and a second screen for the home PC, how would I copy/paste contents between the two? I don’t know yet.
  3. How about running NX Client on the Windows side of my personal PC? Yes, it would be possible. I could even go as far and crazy as purchasing a license of Microsoft’s Office to get Outlook set up, Lync could work as a charm, some colleagues got it set up, but my PC runs Windows 8.1, so back at square 1!
  4. Downgrade to Windows 7 or purchase a separate cheap PC with Windows 7, and install a setup on this. Well, that’s possible, but I am still left with no good solution for Outlook, unless I purchase a license that will be locked to that cheap PC. If I have to purchase Office, I would like to make use of it on my main computer, to maximize my investment!
  5. Wipe the ultrabook and install Linux on it. Well, the machine is intended to be used for testing a Windows application developed by my company, so I cannot just thrash Windows and toss Linux in blindly. I would also be in a similar situation to my personal PC running Linux: partial Lync with no or brittle voice chat, no convenient access to my Outlook mail.
  6. Install VirtualBox on the ultrabook and set up Linux on a virtual machine. I tried it, it almost worked on my personal computer, but it failed when transferring the VirtualBox setup to my ultrabook. Symantec Endpoint Protection, used by my company, screws up VirtualBox’s executable, making it complain it cannot run. I tried to add exceptions covering every executable in VirtualBox’s directory to no avail. It seems that this requires changes to the profile policy using a management application I don’t have. Since VirtualBox is also causing random erratic behaviors, like Alt Gr sometimes not working, Alt-tab sometimes switching out of the VM, etc., I gave up on this. If I had to continue exploring this path, I would try exporting the XML profile of SEP, altering it and reimporting, similar to what I did to get rid of the password protection that was preventing me from uninstalling and reinstalling after upgrade to Windows 8.1 broke it.
  7. Use something else than NX. I tried to find an open source NX client that would have less problem: no go. I really have to give up on NX completely. There are two main alternatives to NX: VNC or plain X using a server such as Cygwin/X or Xming. Because of other problems I will cover below, I finally fell back to VNC which is working better although a bit sluggish.

Update August 5 2014: yesterday, I tried again and my Windows 8 company’s ultrabook got connected using the NX Client 3 with almost native screen resolution. Putting the client in full screen bumped the resolution to native 1680×1050! Probably some NX processes were kept running in the background and a reboot was necessary for the disabling of DPI scaling to take effect. On August 5, during the evening, I tested the NX Client on my personal Windows 8 computer. I got the previous low resolution. I then disabled DPI scaling for the following executables in the C:\Program Files (x86)\NX Client for Windows and its bin subdirectory: nxclient.exe, nxauth.exe, nxesd.exe, nxfind.exe, nxkill.exe, nxservice.exe, nxssh.exe, and NXWin.exe. I’m not sure all these are necessary to change, but I did them all. Then a reboot later, I was getting the native resolution on my personal computer as well. So the fix is reproducible!

Two versions, two protocols

My company is using NX 3 while the newest version is 4. In theory, this shouldn’t be a problem as it should be possible to download previous versions or, even better, use newest client with previous server. In practice, this is not exactly the case. First, only NX 4 can be obtained for free from NoMachine. Getting previous versions requires to be a registered customer. My company is providing binaries for NX 3, but only for Windows and Mac OS X. This caused me additional difficulties to test things in Ubuntu.

By default, NX client 4 won’t work with NX server 3, but it is perfectly possible to configure it to work by doing as follows.

When starting the client for the first time, a screen similar to the one displayed below shows up and needs to be dismissed by clicking on the Continue button.


That leads to a second window similar to what follows. That one needs to be dismissed as well using the Continue button.


Then you end up at the main screen where connections can be added, removed or edited. This looks like the image below.


Click on the New button to create a new connection. This pops up a window similar to below.


The first important setting is the protocol; it needs to be SSH, not NX. This is probably because NX 3 was working on top of SSH while NX 4 has its own TCP/IP protocol. Anyway, selecting SSH is necessary for the connection to work. After that, click Continue to go to the next step: a screen allowing to enter the host name of the NX server.


On the next screen (after clicking Continue), you need to perform an additional setting: set the connection type to “Use the NoMachine login”.. The system login seems to work only with NX 4.


Leave the next two screens as they are.



Then you have the opportunity to name the connection. This is just for convenience; this doesn’t affect the ability to connect at all.


After all these steps, you end up at the central menu and can double-click on the newly created connection. You might get a screen similar to the following one. Click Yes to accept the authority of the NX server.


After this you have to enter your regular user name and password.


Then you have to double-click on the virtual desktop you want to create.


Three more screens to dismiss…




At this point, I got some trouble connecting when I tried to update from NX Client 3 to 4 under Windows. The Ubuntu setup worked very well, on the other end. Looking at the logs, I found out errors about cache and had to remove files from an hidden directory I couldn’t access from the Explorer without copy/pasting the name from the log file! The directory wouldn’t show up, even though Explorer is configured to show hidden files for me, and it would not Tab-complete under GNU Emacs.

Almost there, would you say, a bit annoyed. Well, no, that’s not the end of the story as you can see on the image below!


How am I supposed to work with such a small screen? Maybe some sighted people are able to, by making fonts tiny, but that’s not acceptable for me. Moreover, ALT-Tab doesn’t work, switching out of the NX window rather than through windows inside the NX desktop.

Fortunately, there are ways to configure things better. First, hit CTRL-ALT-0 (zero, not o). That leads to a new menu with options not available through the connection preferences.


First click on Input. That leads to a window from which you can check Grab the keyboard input. This makes ALT-Tab working inside NX, with fortunately significant drawbacks covered in the next section. Dismiss by clicking Done.


Then click the Display button. Select Resize remote screen, dismiss with Done.


Dismiss the main window with Done and tada!


Yes, a fully functional GNOME desktop running inside the NX client. Phew! What a ride!

And that’s not the end…

What’s the point of having a keyboard if it doesn’t work?

Well, I asked myself this question countless number of times while working with NX. This is so erratic, so frustrating, that this was getting on my nerves at times. I strongly rely on keyboard shortcuts for my daily work. Without them, I am completely inefficient, spending a significant amount of time and wasting energy searching for my mouse pointer. Until touch screens spread out and are available in 22″ and bigger formats, I will be stuck dealing with the mouse and working around with keyboard shortcuts as much as I can.

Here are the issues I ran into related to the keyboard, under NX client, both 3 and 4 versions.

  1. CTRL-ALT-<arrow keys> doesn’t allow to switch desktop when NX runs under Windows with Virtuawin, a software tool to add multiple desktops lacking under Windows for years. When I was using the keys, Virtuawin was taking over and getting me out of NX, so I could not use multiple desktops inside NX. To enable this, I had to remap the keys of GNOME inside NX. I could as well remap Virtuawin’s keys.
  2. After approximately one week of usage, NX client started to go crazy with the Alt Gr (right Alt) key. I rely on this key to produce many special characters like @, [, ], {, }, etc., because I am using a Canadian French keyboard. Sometimes, the Alt Gr combination was just doing nothing so I had to type it many times (sometimes more than ten) until the character pops up. Sometimes, the session was getting stuck with no keyboard functionality for at least thirty seconds (mouse was continuing to work). With NX 4, things got worse: no more Alt Gr at all! Running xev, I found that the right Alt key was generating Left Control events instead. Workaround? Well, disable Grab keyboard input! But that makes Alt-Tab non-functional. Alt-Tab is one of my most critical keyboard shortcuts! Without it, I have no efficient way to switch between windows! Well, I remapped the key in GNOME to Ctrl-Tab. This was a bit annoying but somewhat working. The problem got worse on August 5 2014, maybe because the virtual machine was running a script performing I/O competing with the bandwith available for NX. It is thus possible that networking issues are dropping some events while the client and server communicate between each other.
  3. With NX 4, sometimes the keyboard stops working altogether and the session locks itself. It is impossible to type any password and very hard to kill the session. I managed to do so by forcibly terminating the NXWin process. Another way is to temporarily turn on Grab keyboard input, type a few characters, then turn it off! This happens at random times, when switching from a Windows application like Outlook or Lync back to NX client. This issue didn’t happen on NX client 3.
  4. On both client versions 3 and 4, the shift key sometimes sticks. The system behaves as if I was pressing and holding shift while I am not. There is no way out except pressing shift repeatedly until it unblocks. Sometimes that requires disconnecting and reconnecting.

So it seems NX is designed for the simplest scenario: US English keyboard with mouse used to switch tasks.

The only workaround I found is pretty heavy weight: install VirtualBox, setup a Ubuntu virtual machine and run NX client from there. It seems that Windows is the one intercepting some keys and not sending them to NX. It could be literally a lot of different applications: Outlook, Lync, Symantec Endpoint Protection, etc. It would be tedious to find the culprit and probably impossible to disable it.

Copy/paste: a random game

Even the simple and common operation of copy/pasting information causes trouble when NX is involved. There are two main types of problems. The first which I found to happen in both NX 3 and NX 4 is the unstability of the clipboard transfer. Sometimes, I copy a block of text into the clipboard and when I try to paste it in another application, nothing happens. It mainly happened when copying from NX and pasting to a Windows application, say Outlook or Lync. Sometimes I am reaching the point of systematically performing the copy operation twice in a row to make sure it will have greater chance to succeed!

Sometimes, after I selected an area to copy, after one second or two, it automatically unselects. If I try to select the area a second time, it unselects again. When that happens, I have to select and very quickly right-click on the area to get access to the Copy command in the contextual menu. This second issue is intermittent and quite annoying. It seems to happen only on CentOS 6.3 virtual machines running GNOME Terminal. I tried to connect to a Ubuntu machine using NX and didn’t get the issue. The problem also didn’t happen when I ran the NX client into VirtualBox, so this might be caused by Windows or some other application.


After the second time NX Client 4 went south with the keyboard, leaving me locked out of my session, I got tired and tried something else: VNC. It happened to be simpler than I thought. I just had to SSH into my virtual machine and type vncserver from there. I had to set up a password for my VNC connection and VNCServer told me the host name and display to use on the VNC Viewer.

I tried with UltraVNC, because that viewer is supporting encrypted connection between client and server. Connection worked like a charm, but keyboard support is quite poor. First, Right Alt, again, is failing. It seemed more and more I would have to switch to US English keyboard to work with that virtual machine. Then I noticed the VNC Viewer was skipping keys randomly. For example, I typed exit and got just the e! So I would have, on each key press, stop and look at the screen if it’s there, and retype it, as many times as I need. I am not used to working like this: I rely on the key presses to work. This is a shortcut that prevents me from getting completely drained out quickly!

After a very frustrating and almost catastrophic failure with the installation of VirtualBox on my company’s ultrabook (the beast didn’t like Symantec Endpoint Protection and messed up with my Internet connection), I tried a second VNC client: TightVNC. It does not encrypt the traffic, but that’s not a big issue since the virtual machine is inside the company’s network and thus access through encrypted VPN. That one worked relatively great with a couple of tweaks and two drawbacks.

Here are the tweaks:

  1. TightVNC is misbehaving under Windows 8 in a way similar to NX Client. However, and fortunately for me, that one can be worked around by disabling DPI scaling just for TightVNC.
  2. Under GNOME, I had to use XRandR to switch resolution, by typing xrandr -s 1680×1050 on a terminal.
  3. I had to switch VNC to full screen using CTRL-ALT-SHIFT-F otherwise some portions of the screen are cut away.

But in full screen, TightVNC completely captures ALT-TAB and CTRL-ALT-<arrow keys>! I have to leave the full screen mode to get the keys back to Windows. Right alt key is also working great. This is very nice, as if I were working under Linux! However,

  1. Performance is not as great as NX. The display is a bit sluggish, although manageable, especially given the incredible benefits I got with Alt-Tab working. However, sometimes, especially when I am working from home, the display refresh becomes very slow and when typing a key, the character appears one second later. In one case, it was so slow that I had to figure out a way to work locally for the rest of the day.
  2. Clipboard support is a bit clunky. I managed to transfer data from VNC to Windows by starting vncconfig -nowin inside my VNC session, but that doesn’t solve the other way round: I cannot transfer data from Windows applications to VNC-managed GNOME session. I couldn’t find any solution for this.

If everything else fails

If VNC fails too at the end, there is little remaining other than establish a traditional SSH connection and working from the terminal. I will need to open a new window and SSH again each time I want a new terminal. I tried to use Screen to have multiple terminals in the same window. That works relatively well except under Emacs because the Ctrl-a key used in the editor conflicts with Screen.

Moreover, Emacs somewhat misbehaves under SSH terminal, at least with Cygwin. Selecting text and typing a key doesn’t overwrite the text, just adds characters besides as if no selection was done. Moreover, Ctrl-Backspace erases a full line rather than the last word.

If I need a graphical display, for any reason, I could start a X server such as Cygwin/X or Xming, run export DISPLAY=:0 and use the -X option to start SSH. With this trick, any X client shows contents on the Windows screen. However, this is pretty slow over a VPN connection. At least, this is a known-good solution. This will almost always work!

Can we make things better?

If the server evolves, yes. There are at least two ways I could think of that would improve things.

  1. X protocol is quite old and clunky. There are new protocols in development that could replace it and be more efficient and compact over VPN. The main one is called Wayland, a completely documented and open protocol. Canonical, the maintainer of the Ubuntu distribution, is also developing its own alternative called Mir. As far as I read, Mir is simpler than Wayland, but it is more closed; only the API is open while the protocol is under Canonical’s exclusive control. Using either Wayland or Mir may result in less traffic, so more efficient graphical sessions over the same network bandwith.
  2. Logging on a centralized server and working from there is the 70’s way! Nowadays, each and every laptop has tremendous CPU power that is shockingly unused when logging in to a remote desktop. What we need here instead is a way to share filesystems, and there are numerous protocols for this: SSHFS, WebDAV, CIFS, etc. One argument against this is probably data security. That would need to be addressed by encrypting hard drives of the laptops mounting file systems with data. Moreover, some work may require the use of Linux, either on bare metal (dual boot laptop) or as virtual machines. The company could provide a prefabricated OS image employees would install and would be free to alter as they see fit, to install new applications or make settings.