Slashdot Mirror
Google Releases Open Source NX Server
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.'"
Poor NoMachine... now they don't have a product
Was ( is ) open source i thought.. Either way, another player isn't a bad thing. Especially if its painless to setup on FreeBSD.
---- Booth was a patriot ----
Is in TFA but not in summary.
Article doesn't state how the NX client from NoMachine is either, which is probably important for people trying it.
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?
And the worms ate into his brain.
XWindows was remote window graphics developed at Stanford and fortified at MIT during the 1980s.
OK, now how about an open source NX client? Preferably one which doesn't fork off a background process to handle the display and then terminate, making it a PITA to use as an XDMCP-replacement on X terminals. Run until my session ends, damn you!
Well this sure beats HTML+HTTP and Javascript for displaying remote applications. Web browsers are horribly inefficient for running remote applications and its good to know somebody is working on a replacement
Of course the obvious problem with this is finding a way to block the ads running in a remote application. Maybe not if they always appear in the same places, but knowing Google I doubt they will.
As a longtime NX user, this will be very well received. I feel like I'm one of a couple dozen NX users, however, meaning that I think this will go largely unnoticed by mainstream users. The non-proprietary NX-server packages are very non-trivial to install and all attempts thus far at a completed server setup have remained inadequate and completely fly-by-night/unmaintained. I hope people start to use this more and thus perhaps even push the technology farther.
put the what in the where?
I wonder whether there are environments where technologies like NeatX can be regarded as "God sent" solutions.
I know the technology and have used it several times but I still fail to see how it could be useful given the enormous power today's systems have.
I guess I am calling for serious implementations...anyone?
I love FreeNX and have used it for a long time, I can't wait to try this...
I also love Python as a language and I used to be an it's C/C++ or Java or it's not worth it.
After falling in love with Python, it is let me see if python can handle this with speed, if not, I'll write a class in C and use python to Access if needed.
I don't really see why they even really need the bash scripts though.
If you use any POSIX system remotely and like GUI's, NX is a must. VNC and Plain X are slow (even with ssh compression)
At the moment, we're not doing releases as we're constantly fixing small things as people try out the codebase.
It might be worth mentioning to some people who are no doubt confused; there is a difference between FreeNX and NX Free. And on a futher side note, I have tried installing FreeNX two or three times and the packages seemed to be unavailable from distro repo or even from the berlios FS (Weird!). In any case if this Google NX server isn't a piece of junk I will be over the moon!
In my opinion NX is #1 remote display (also sound and printing) technology there is. You get a great quality image over a very slow DSL connection! VNC doesn't come anywhere near it - and for the $0 price tag you can't beat it!
The trouble with NX Free is that it can only allow a few simultaneous connections at a time - I'm hoping Google's server changes this.
If Google is serious about Android and Chrome OS, then they will build something like Apple's Quartz. There is no substitute for doing this all in OpenGL.
Am I the only one concerned that a company known for collecting tons of data about people has announced a remote desktop product at the same time as they announced a new, slimmed down OS revolving around having an Internet connection?
*shiver*
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
If you were on Verizon you would have a network of weird looking guys behind you, holding implements that may have been useful in that situation.
This is excellent news, I've really enjoyed using NX but always found it slightly temperamental to use. Still, it gave me high performance rootless application access over a dodgy wifi link in Germany, back to my machine at uni in the UK - with the ability to resume every time the wifi dropped. I've known people have trouble resuming dropped sessions, though it worked when I needed it. Anything which is well-supported and makes NX nicer to work with is very welcome - I hope Google press on with making this better and better. It's be real nice if they'd make an open source client available too, preferably with a choice of front-end widget libraries ;-)
Another project, which I actually head about on Slashdot and am very impressed by is Xpra: http://partiwm.org/wiki/xpra
Xpra = X Persistent Remote Applications, i.e. connect to your xpra server (tunnels through ssh by default) to get rootless applications delivered to your desktop, disconnect and reconnect somewhere else and get the same apps back. Like screen, for X. It's not meant for fast-changing displays, e.g. video. But it's a nice, compact approach that largely consists of a few thousand lines of Python. It uses modern X extensions cunningly to get the job done without having to understand most of the X protocol itself. And, somewhat like NX, it's better suited to high latency links than simple X11 protocol is. These days I think Xpra is starting to get more advanced features such as Windows client support, theme matching for remote and local apps, some clipboard sharing, etc. It's a nice little app that has its uses, particularly if you want something simpler than NX to set up and administer. The server can also be easily run by an unprivileged user whereas I'm not sure if that's the case for NX (?).
Actually, replying to myself: what I'd *really* like to see is some funky modern window manager that leverages X11 extensions in a similar way to Xpra to enable forwarding of apps I started *locally* over some network protocol. Perhaps there's a reason this can't be done but I'm not really sure what it could be? I don't want to have to decide in advance which apps I might want to migrate - and I don't want to suffer performance penalties whilst I'm not remoting them.
Xpra, sadly, can only display apps you explicitly ran against the Xpra server. NX is the same. You can't just use it to access some random app you're running on your desktop at home. I've tried putting certain key apps into Xpra and then *always* "remoting" them, even when I'm on my home system. It works but it's a waste of resources and it's going to slow stuff down a bit (depending on what you're doing). I'd really like to get full Video / OpenGL performance from my apps when I'm at my machine but still be able to remote those apps in a performance-degraded way without restarting them.
a free oss server... that's good news. Is there source for the neatx client somewhere?
The Admin and the Engineer
A link to the announcement from Google.
Hmm, lost in the shuffle of the Chrome OS announcement... but maybe it's related? I can see such a component being hugely useful on Chrome OS.
"sudo make me a sandwich" -XKCD
So who wants to guess they'll use this with their newly announced "Chrome OS" along with a custom URI scheme handler (ex: "telnet://xxxx" or "apt:xxxxx") where following that link launches the appropriate program. Chrome OS would basically only need 2 or 3 apps for the user to interact with - X-server, Chrome, and NeatX. You wanna use an actual office suite instead of Google Docs? Launch K-Office via the a custom Google homepage, it runs remotely on cloud servers (which you may or may not need a subscription for). This allows manufacturers to use even more low power hardware, you get better battery life, Google gets to mine your data for advertising, and it uses that cell carrier 3G connection even more, allowing the carrier to charge you more...
The one thing that keeps me from running NX is that it won't let me connect to my session unless both the server and client run the exact same color depth. With VNC, I can connect to my 16-bit color X session at home on my 32-bit color Windows client at work. With NX, unless both desktops are running the exact same color depth, it won't connect. If there's a way around this, Google's search hasn't shown me anything.
For those of us that commonly work with compute servers / vm's, etc. NX can be tremendous. One anecdote -- I sometimes run Maple (X or IX I forget the version) on my server and display on my desktop. The version I have uses JAVA's Swing widgets. Its pathetically rough over a remote X connection, even the 1Gb connection I have in the lab. I tried running the same session over the NX protocol using my laptop at home on a relatively slow cable connection (something like 256Kb). It was dramatically smoother and more responsive.
Sun Secure Global Desktop.
You could use X over a dial-up connection on Motif or Athena. Of course it's not the bandwidth, it's the latency. And the latency of a 14.4K connection is pretty acceptable if you turn off MNP5 and other compression junk, even though X protocol compresses very well the modems tend to have worse latency with the built-in compression. LBX (low bandwidth X) was usually a better compromise than running the general purpose compression, if you were lucky enough to have hosts with the LBX patches installed.
“Common sense is not so common.” — Voltaire
Congratulations Google, you've re-invented Low Bandwidth X!
Also see, An LBX Postmortem.
It must have been something you assimilated. . . .
I work for a large corporation that uses VNC,and several years ago I tried to install NX at work, hoping to get a speed boost when working remotely. Unfortunately, the creation of a user "nx" was required. I'm not in the IT department, I don't have root access, and they IT department had no interest in deploying NX. So I gave up.
I saw this announcement and hoped that an "nx" user would no longer be required, but it appears this is still necessary. If I could get it installed and it actually worked better I know the other engineers would jump on it and eventually IT would be forced to support it.
Anyone have a workaround?
He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.
I work with both MS and Linux servers and, when setting up my own home server, I had a choice between the platforms. Seeing as how I have a TechNet subscription for work/testing purposes Server 2008 is basically free for me so the choice was not one on price but on ease of use and applicability to my needs.
I ended up installing Server 2008 with Linux running under a VM for the occasional usage mostly because of how great Terminal Services is. It gives me a remote desktop through a fast, secure, and very functional protocol which is widely supported. If I get disconnected I have it set up where it will maintain all of my apps just as I left them for days. It maps my local clipboard, printer and local drives wherever I am and there are clients on every windows PC, for the Mac, for Linux and even for my iPhone.
Microsoft is making a move in this space releasing features for Terminal Services 2008 that used to be limited to Citrix - secure https gateway, load balancing between servers and accessing individual applications through a web interface. And since you always had to buy Terminal Services CALs in order to use Citrix anyway (you have to love that - make your customers buy our product to use your product and we'll let you survive) it makes the MS solution much cheaper than a terminal server used to cost with Citrix.
I just find it funny that there is another area - thin clients and remote workers - where MS is trying to assert their dominanace, albiet with a great product, and Google happens to come along and release a free alternative.
You sir, are every IT departments nightmare.
- sarcasm is just one more service we offer -
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.
I'm a VNC user, but I realize some of the benefits of NX. (Sound...performance...etc.)
However...I couldn't get past the start-up times. With VNC, I'd 'click' and poof, my applications would be right were I left them, continuing on as if I'd never left. If I closed the window, the applications didn't even know I was gone.
With NX, I'd connect, I'd go through a big start-up process, I'd log in, and wait for my windows to open.... If I wanted to leave, I'd click on the 'I'm leaving now' and it would put everything into a state to where I could come back to it, etc etc. (granted my remote machine was no speed demon.)
So, finally I went back to VNC. I tend to have the window go up and down quite frequently, and the startup/shutdown times of NX were just a deal breaker.
If I was going to use it as more of a truly 'remote terminal' when I'd have it up for hours at a time, then perhaps the heavily loaded ends wouldn't bother me.
--Welcome to the Realm of the Hawke--
> I'm not in the IT department, I don't have root access,
Yah... I don't think you should be enabling RPD or installing VNC either then
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
I worked for the company that developed it almost 20 years ago. It sought to accomplish much the same thing, and though "Internet" wasn't part of the marketing it was definitely intended to work over a standard IP network. The company used it in-house to run common applications on one or two "app servers", which were then served via the DesqView/X clients to Windows workstations throughout the company. IIRC there was only one, maybe two, competing products in the market at the time. It was capable of serving Windows to a UNIX workstation, and vice versa, all done via X-Windows protocol.
Really products like that are the direct predecessors of these revamped Internet-specific products we're seeing now.
From what I've read so far, they have gone out of their way to implement ChromeOS without using X Windows and instead going with something proprietary and in-house.
It just seems odd that they are also releasing a server that dishes out X Windows sessions remotely. This must not be meant to integrate with Chrome OS. I guess they could still have a client for it in Chrome OS, but it still just seems odd to me.
THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE
I also am a huge fan of NX. The one drawback that I encountered after I switched to a Mac laptop is that the NoMachine NX client for Macs does not work in fullscreen mode (in fact, it seems like that is the fault of Apple's X server, and they don't have any intention to fix it). A side-effect is that all key combinations are interpreted by Leopard's window manager first, so I can't use any of my usual shortcuts in the NX session. All of this works perfectly in the linux client, now I am hoping to find the same bliss for the Mac.
The ~50 engineers at my workplace switched to NX 2 years ago. There have been many complaints about the instability of NX ever since. Sometimes engineers lose a handle on a simulation that has been running for more than 24 hours and have to start over. I stayed with VNC and lately people are asking me how to switch back.
For me, (Ultra)VNC has been rock-solid. If Google can make NX reliable, maybe I'll make the move, too.
Anyone else have complaints about NX stability?
I've tried NoMachine and found it the most responsive compared to other solutions. Of course the GUI is over rated, as any dyed in the wool techie uses SSH + BASH + MC + PINE ...
Actually the "nx" user isn't required, neatx supports operating without. However, NoMachine's nxclient doesn't support this, as it assumes that it should always log in as the "nx" user. So, if you're using !M's nxclient, you need to do a small bit of modification client-side. Here's an example of what to do client-side (though the beginning of the post is specific to FreeNX): http://www.felipe-alfaro.org/blog/2009/01/18/freenx-usermode-authentication-and-mac-os-x/
Steve, Neatx project lead
Time. Time seems... strange.
I don't know why you assume a forwarding proxy will suck. I've used a few - there was a neat one whose name escapes me which connected to multiple X servers and let you drag windows between them. Performance was fine. You can't use shared memory - but then you can't use shared memory for remote X11 either. A quick google tells me that xmove does exactly what you want. The guievict project created an extension which allowed checkpointing the window state and moving application display to another server, but their implementation was LGPL'd so never got incorporated into XFree86/X.org.
I am TheRaven on Soylent News
Can't you run it as your own user?
But how many developers have nightmares at the thought of dealign with their IT department? I know I do...
Replying here to both your post and the one you replied to:
As I understand it, Xpra's cunning hack is to run a real X server (such as Xvfb, which just "displays" to some memory for debugging purposes - or even Xvnc (!)) somewhere. Then the Xpra server registers itself as a compositing manager (so the complete contents of windows get handed to it for compositing). The server uses XDamage (notification on bits of windows that changed, I think) to get told when some contents change, then reaches into the window content it's being asked to composite and squirts that over the network. The client side, speaking *very* loosely, just displays windows and fills them with the bitmapped content it's being sent by the server. Nice thing here is that it's windowing aware (unlike VNC) so can forward rootless apps but it doesn't need to screen scrape or proxy the X connections themselves. There's more cleverness in the implementation than I've described, in order to make interaction, etc work. But that's the basic trick.
Now, the thing I'm wondering - and I think there *is* a reason but I can't remember what it is... I'd like a normal compositing WM on my desktop to be able to take over this role. So it would act like a normal WM to me whilst I'm using my desktop but if I connect remotely it'll be able to send the bitmapped contents of windows to the remote system. One thing I can imagine being a problem is that when I resized windows at the "other end" they'd end up getting resize events locally too. But I could live with that, especially if the WM moved them back when I disconnect. I should ask on the Xpra mailing list, really.
If the thing could detect when an app is trying to accelerated video GL and switch to using some kind of lossy video codec to stream current content to the other end that would be even better.
Let us not forget that FreeNX and NX in general appears to use SSH as it's only needed port allowing not only normal SSH terminal activity but also NX connectivity using only 1 port with default SSH encrypted packets so they cannot easily reconstruct the transmitted data in the event of an interception.
-=[ Who Is John Galt? ]=-
i.e. you have a Windows server and a Linux client. Might not be enough for your purposes though.
I'm not sure why you're replying to me - I deliberately didn't mention Xpra because it's an ugly hack which manages to combine the worst aspects of X11 and VNC. The correct way of doing this, which xmove does, is to simply track the very small amount of state that exists for each window and use this in a CreateWindow message to a new server when you want to move windows, and just proxy all other messages directly.
I am TheRaven on Soylent News
Funny I'm actually using NX right now. NoMachine hasn't released an update for their client in eons, and there are plenty of bugs that irk me. Maybe this competition will whip them into shape. Or maybe I'll switch...
So first, this still requires nomachines nx core, seems like, so it cannot claim to be completely pure.
Secondly, though they don't use Tcl expect, they are still doing the same exact thing, but in python. The problem here is when writing expect stuff, you are already in a bad spot as unexpected input comes up. For example, in trying neatx, I already noted their expect code wasn't expecting a password prompt common in a kerberos environment. And when things go off-the-rails in an expect context, you return to the client an extremely unhelpful, obscure error.
Thirdly, it is all trying to interoperate with NX's rather unfortunate mode of operation where the service is accessed via ssh to another user, even though the goal is just to 'su' to the user you want to be. Considering nx requires you ta have a normal *nix account anyway, I don't get why they implemented this goofy nx user.
NX has long been a source of some frustration to me. FreeNX has been promising, but subject to all sorts of weirdness (sessions suspended being lost because they go to closed, suspneded sessions that cannot be resumed for unknown reasons, etc). I really really want the technology NX has to offer, but all the implementations I've tried thusfar have design decisions that are unfortunate and implementations with mysterious bugs and a user community that is unfortunately weak.
Almost all of this is the fault of the code at the NeatX/FreeNX layer rather than the core. But given the inherently goofy design they are having to emulate, I can't blame them. I would *LOVE* to see an implementation throw out Nomachine's architecture and do a more sane, per user scheme.
XML is like violence. If it doesn't solve the problem, use more.
I'm not sure why you're replying to me
Because you were participating in the discussion about how to forward local apps onto the network, so I thought further discussion was relevant to you too.
- I deliberately didn't mention Xpra because it's an ugly hack which manages to combine the worst aspects of X11 and VNC.
*shrug* one man's meat is another man's poison. That's one way of looking at it but it also manages to combine some of the strengths of each - rootless operation, simplicity and latency tolerance. You can also upgrade the server without losing your apps.
In my opinion Xpra is an elegant use of existing infrastructure to create a minimal solution to a problem a number of us have. I can run Xpra on my work machine, then connect remotely. Attractive to folks need to remotely access a graphical app without high performance but want a guarantee that a network crash won't kill their app. It's not the only way of doing this but it has simplicity on its side.
Moreover, unlike X protocol, which xmove uses, Xpra's protocol is suitable for high latency links and doesn't require the client machine to have an X server running (c.f. the Windows port).
Horses for courses. I just wouldn't use it for everything is all ;-)
The correct way of doing this, which xmove does, is to simply track the very small amount of state that exists for each window and use this in a CreateWindow message to a new server when you want to move windows, and just proxy all other messages directly.
I always liked the idea of xmove but I thought it was hadn't been maintained for a while? Does it actually still work well with modern apps? Do you use it?
Yes, you could have stopped after the word "think".
We have and use VNC. It's supported and we depend on it. I did install and enable unsupported VNC clients like TightVNC to try to get some more speed. NX is the next step. You can argue whether or not users should be installing potentially insecure networking servers, and you can argue about productivity.
When working remotely everything is over VPN anyway.
He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.
Thank you, I will check this out.
He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.
One of the few things left in Linux that hasn't really been worked out yet (well..decently) is remote GUI access. I had tried exporting X via ssh and using VNC, both of which were completely unacceptable solutions to a "remote desktop" solution over the Internet. FreeNX however was quite nice, but didn't play very well with KDE4 and multiple displays; after a FreeNX session, I'd come back to my office workstation only to find my desktop completely bastardized. Hopefully google's implementation of NX fixes that.
Let's face it, NXserver may have fixed a performance issue but as I recall it still couldn't enable you for common remote situations, like connect to an existing desktop or share an application window with someone else (at least not without resorting to VNC). You were still limited to viewing one app by only one person, so an app window launched on my machine by a remote NX user wasn't even visible to me locally. If the remote user logged into the existing 'Burz' desktop, they would get a separate instance of it.... not very useful.
I remember reading this was a limitation of X11 and/or NXserver internals. If its the former, then we really need to wake up and dump this architecture quick. If the latter, then hopefully Google will be able to contribute in these areas.
Also, NXserver made you reconfigure ssh to where key-only logins weren't possible. Hampering ssh like this shouldn't be necessary.
Hi,
I'm using the pathetically slow VNC protocol (even on a LAN it's a pain) to access my Mac Mini from my Linux workstation. To access Windows system, I use Windows' remote desktop which rocks (Windows suck big megadonkey balls IMHO, but their remote desktop protocol is good). To access other Unix system I use FreeNX, which rocks even more (this pwns Windows remote desktop in unimaginable ways), someone mentionned using X over a 19200 baud connection, FreeNX is just *that* fast.
But is there a way to access OS X remotely on Linux that sucks less than VNC?
WTF?
This isn't the kind of thing that users should install...and from your post, I would say especially not you.
NX is perfectly fine and stable for me, but I'm also not using it to run simulations or anything where I would come back to it a few days later and see what's up. For that kind of work, VNC might actually work better. These simulations are directly tied to a GUI app? They can't just run in the background?
Change your name to Nicolopolous Xanzapooo
(Or buy your IT guys beer.)
I use NX all the time -- I'm using it now. My main desktop is on a VPS account, that I hit from both work and home.
The criticisms of the NX server are right on the money. It's pretty rough. Problems don't get fixed, and it doesn't move forward.
I doubt this is what Google is thinking, but it seems to me that NX represents an alternative way to do the cloud. I have everything in the cloud -- a full suite of desktop apps -- because I use my VPS and NX. It all just works. And it's all under my control. There aren't any privacy issues.
So I'm really pleased by this development.
Thanks to the folks at Google for this project.
reading webpages on a remote X connection on an Amiga 1200. Because there were no browsers that could handle tables for Workbench..
http://openfacts.berlios.de/index-en.phtml?title=FreeNX_Howto