Google Releases Open Source NX Server 257
Posted
by
ScuttleMonkey
from the free-and-good-together-defies-reason dept.
from the free-and-good-together-defies-reason dept.
wisesifu writes with news of a new open source NX server, dubbed NeatX, that was released by Google and promptly lost in the shuffle of the Chrome OS announcement. "NX technology was developed by NoMachine to handle remote X Window connections and make a graphical desktop display usable over the Internet. By its own admission, Google has been looking at remote desktop technologies for 'quite a while' and decided to develop Neatx as existing NX server products are either proprietary or difficult to maintain. 'The good old X Window system can be used over the network, but it has issues with network latency and bandwidth. Neatx remedies some of these issues,' Google engineers wrote on the company's open source blog. NoMachine had released parts of the source code to its NX product under the GPL, but the NX server remained proprietary. [...] Neatx is written in Python, with a few wrapper scripts in Bash and one program written in C 'for performance reasons.'"
NIH (Score:5, Insightful)
From TFA:
"There is a free implementation of an NX server based on NoMachine's libraries named FreeNX, but this did not appeal to Google.
"FreeNX's primary target is to replace the one closed component and is written in a mix of several thousand lines of Bash, Expect and C, making FreeNX difficult to maintain," according to Google.
Neatx is written in Python, with a few wrapper scripts in Bash and one program written in C "for performance reasons". "
It was unmaintainable because it was written in Bash, Expect, and C, so they rewrote it in Bash, Python, and C?
Re:Sucks to be NoMachine (Score:5, Insightful)
FreeNX has been around for quite some time and that hasn't killed NoMachine off. However, Google being involved may create more OpenSource developer interest in NX and perhaps someone will create a good Windows NX Server, Windows NX Client and better management tools. If Google rallies that much developer support it could mean an end to NoMachine.
Re:NIH (Score:4, Insightful)
In other words: Those who do not understand Haskell (which admittedly is hard if your brain is limited to OOP and procedural coding), will re-implement it
This just screams a "fixed that for you" post... I think you mean Lisp, don't you?
Re:Still requires creation of user "nx"? Noooooo! (Score:5, Insightful)
You sir, are every IT departments nightmare.
Re:Beats Web-apps (Score:4, Insightful)
Well this sure beats HTML+HTTP and Javascript for displaying remote applications.
I'm so tired of people comparing web apps and X. They are completely different beasts.
Web apps are downloaded to your local PC and run there. Many web apps make frequent HTTP calls to sync with, or access resources, on the server, but that's completely optional. Web apps are often the right solution compared to X apps because they leverage the power of your local PC. While writing this comment, my local PC did the spell checking, it handled the keyboard events, and it updated the display, all without any communication to, or from, the server. It was fast and responsive and efficient because it all happened entirely on my local PC. The only communication that will occur with the server is when I click on Submit.
In contrast, X apps are run on the server and merely displayed on your local PC. Slashdot could not possibly function that way without enormous hardware and bandwidth upgrades, and even then it would probably be an annoying experience for many users on connections that experience frequent lag.
Web apps and X apps are not really competitors. They serve two different purposes. Web apps leverage the local PC and can also leverage the server where it makes sense. X apps are basically entirely run on the server with only display updates being sent to the client. This setup made sense a long time ago when servers were extremely powerful and client PCs were weak. Now that even modest hardware is extremely powerful, X makes very little sense.
Re:Sucks to be NoMachine (Score:3, Insightful)
So Google is about to launch a product providing remote desktops, vendors will build thin-terminals around it, and NoMachines has a commercially-available well-tested server ready to sell with support for in-house use of these terminals... I think they'll be OK, once the corks stop popping.
Re:Good news well done Google. Another option is x (Score:1, Insightful)
Xpra, sadly, can only display apps you explicitly ran against the Xpra server. NX is the same
VNC's solution was to have a module installed in X.org itself to allow it to read off of the display there (where it provides everything, not just selected windows). The problem is that there is a lot of state held in the X server itself that would need to move with the app, and right now the "normal" X servers aren't written to give it up. That leaves re-writing every app individually to give them the ability to recreate its state on another display, or writing an intermediate server to handle the recreation part transparently to the application.
Ultimately, if there's going to be a permanent answer that would please everyone involved, it's going to be that xlib and the X Protocol will have to be re-written/extended to allow applications to change servers mid-connection from an external signal. I'm not sure that this would ever work (well) with GL, since the entire rendering pipeline would have to be swapped out at that point, and the app has probably already made a number of assumptions based on GL performance and features at startup that may no longer hold.
Second place would be for the X server to be allowed to act as a forwarding proxy for selected connections. On request, the X server itself would then handle the setup of the new window and start forwarding all of the traffic back and forth between the client and the actual display. The performance will suck, the bandwidth will suck more, and the security and stability issues will pretty much ensure it dies an early death.