Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
KDE GUI Software The Internet

NX - A Revolution In Network Computing? 404

Anonymous Coward writes "Judging from this interview, it looks like KDE developers have found a new toy to add to their desktop's networking capabilities. They claim to be able to cram a fullscreen KDE session -- KMail for mailing, Konqueror for file management, Mozilla for web browsing and OpenOffice for word processing -- into a 40 KBit/sec modem connection without losing responsiveness for the user experience. At aKademy, the 9 day KDE Community World Summit, a group of core developers started to work on NX/FreeNX integration to help facilitate the "re-invention of the KDE desktop environment" for KDE4. Knoppix-3.6 is the first Linux distribution to ship an integrated FreeNX server (created by Fabian Franz) with the NoMachine NX Client."
This discussion has been archived. No new comments can be posted.

NX - A Revolution In Network Computing?

Comments Filter:
  • Re:Not Any Time Soon (Score:4, Informative)

    by dago ( 25724 ) on Tuesday August 31, 2004 @02:32PM (#10121009)
    Warning : Acronym Collision

    The correct moderation to apply to the parent post is either "Offtopic" or "Funny", the latter being more my choice

    Quick karma whoring :
    - AMD NX : No Execute, prevention of buffer overflow (stupid webpage here [amd.com], search google for AMD NX)
    - nomachine NX technology (website [nomachine.com]), which is, functionnality-wise, the sucessor of VNC

  • by UnderScan ( 470605 ) <jjp6893@netscap e . n et> on Tuesday August 31, 2004 @02:34PM (#10121031)
    Introduction to NX technology [nomachine.com]
    A brief introduction to NX motivation and technology
    This document outlines the background and the design decisions that guided NX development. It explains why NX is different from similar technologies and states the goals the NX project is set to pursue.
  • Re:Not Any Time Soon (Score:5, Informative)

    by Anonymous Coward on Tuesday August 31, 2004 @02:36PM (#10121055)
    NX will be useless until a sufficient portion of programs support it.

    You are completely right in that, mate!

    However, please take note of the fact that virtually all (meaning 100%) of all X11 programs already support it. I have used NX successfully with KDE (each single damn program of the lot), GNOME (most of their programs -- I have abandoned GNOME as my default desktop a year ago), ICEwm, OpenOffice.org, Acrobat Reader, Mozilla, Firefox, Abiword, and a bunch of others. They all worked.

    The reason is simple: NX uses the X11 protocoll (which each X11 program uses) and translates it into its own NX calls to bridge the remote link distance. After the bridging, it re-translates it into X11 and, voila!, the local X-server displays the X app's GUI without a hitch...

  • Re:Educate me. (Score:5, Informative)

    by hummassa ( 157160 ) on Tuesday August 31, 2004 @02:44PM (#10121142) Homepage Journal
    It's a remote graphics protocol based on X11, but with considerably less round-trips, due to aggressive caching on both sides.

    Trying to be more plain:

    imagine the work when you click on a button (exaggerated):

    server: move your mouse position to x1, y1
    client: move your mouse cursor to x1, y1
    .
    .
    .
    server: move your mouse position to x2, y2
    client: move your mouse cursor to x2, y2; highlight button(button 1)
    .
    .
    .
    server: move your mouse position to x3, y3;
    client: move your mouse cursor to x3, y3;
    server: mouse down
    client: display pressed button
    server: mouse up
    client: display pressed button (client will now do the ON_CLICK event)

    under NX:

    server: button(button 1) was clicked
    client: does the ON_CLICK event

  • Re:Not Any Time Soon (Score:1, Informative)

    by je4d ( 254907 ) on Tuesday August 31, 2004 @02:46PM (#10121166)
    Nomachine's NX doesn't need applications or toolkits to be reimplemented to run over it. It works by applying intelligent compression to the X protocol, so any X application can run over it unmodified - this includes KDE, Mozilla, GNOME, whatever.

    The KDE integration is only in the kNX client, which takes advantage of KDE technologies such as kwallet, dcop, etc (unlike the 'official' NX client which is pure qt).
  • by Vexler ( 127353 ) on Tuesday August 31, 2004 @02:47PM (#10121171) Journal
    An earlier poster replied that Microsoft has had this for years by using RDP. That configuration is not bad, but I would say that the Citrix ICA/IMA architecture has that beat, and more. (ICA/IMA is better at handling burst traffic, and compression is more efficient.)

    My company deployed more than twenty-five thin clients in addition to many PC-based virtual sessions that allow the back-end servers to do the number crunching. Each thin client session uses no more than 7-8 Kbps to maintain screen updates, and responsiveness is limited only by the capabilities of the servers and the network bandwidth available.
  • by Anonymous Coward on Tuesday August 31, 2004 @02:47PM (#10121176)
    NoMachine begs to differ as they actually helped in the developement of FreeNX.
  • by omega9 ( 138280 ) on Tuesday August 31, 2004 @02:48PM (#10121192)
    To clarify the parent a little,

    The client side comes stock on NT, 2k Pro and Server*, XP Pro and 2k3 Server*. However the MS RDP client is downloadable for free from their site.

    The server side only comes stock on NT,2k, and 2k3 Servers, not the workstation OSs. And even then, you have get a single "stock" license, so no more than one connection at a time unless you shell out some bucks.
  • Re:Educate me. (Score:5, Informative)

    by ahfoo ( 223186 ) on Tuesday August 31, 2004 @02:51PM (#10121222) Journal
    I think the app has to be NX-aware for it to work, however...

    I don't think you're right on that point. I downloaded the Knoppix3.6 iso with Bittorrent almost a week ago and I've been using Fabian's NX server the whole time since then. It gives you everything you get in a regular Knoppix KDE desktop. You can burn DVDs using K3B from a machine in another room among other things I've been doing lately.
    I just wish there was some way to make it work at boot time so I could ditch my KVMs.
    I did see that small /. thread on hardware IP KVMs the other day though. Sounded great, but I don't have one to play with. But hey if KVM over IP works for hardware, why not software. Sounds crazy, but you never know.
  • by Master of Transhuman ( 597628 ) on Tuesday August 31, 2004 @02:51PM (#10121223) Homepage
    "They claim to be able to cram a fullscreen KDE session -- KMail for mailing, Konqueror for file management, Mozilla for web browsing and OpenOffice for word processing -- into a 40 KBit/sec modem connection without losing responsiveness for the user experience."

    No, they do NOT. The interviewed persons state that a responsive NX session requires a 40kbps link, and about 25MB of RAM. This allows you to run a KDE session remotely and also allows non-KDE apps like Open Office to run remotely.

    They do NOT say that you can cram ALL of those programs SIMULTANEOUSLY INTERACTING into that 40kbps.

    Obviously they mean you can interact with all of those programs over that link - one program at a time, switching between programs, just like any other remote-control software.

    They estimate that a modern PC with 1GB of RAM and a 3GHz CPU could support 25 simultaneous fullscreen KDE remote sessions, crapping out at 35 sessions.

    As for usefulness of this technology, they list at least nine scenarios and benefits of using it.

    One of which is that it eases Linux adoption on the desktop by allowing Linux clients to access Windows apps running on Windows servers and vice versa, thereby allowing companies to migrate from Windows to Linux at their own pace and not forcing them to find equivalent Linux programs for various Windows-only mission-critical programs. In other words, migration doesn't have to be all or nothing.

    Is this too hard for ./'ers to comprehend?

  • by hummassa ( 157160 ) on Tuesday August 31, 2004 @02:54PM (#10121258) Homepage Journal
    1. no it does not.
    2. we (www.almg.gov.br = Minas Gerais [3rd largest economy of Brasil] State House) just switched 700 copies of MSoffice97 for OOo1.1.2; with NO PAIN at all.

    Just do it. Proper training, some care, ok, but just do it.

    []s
  • Re:diff NX LBX? (Score:4, Informative)

    by leandrod ( 17766 ) <{gro.sartud} {ta} {l}> on Tuesday August 31, 2004 @02:59PM (#10121324) Homepage Journal
    >
    How is NX different from the Low Bandwidth X (LBX) extension for the X windowing system

    It works.

    And BTW, it works with anything X11 too.

  • by stratjakt ( 596332 ) on Tuesday August 31, 2004 @03:01PM (#10121342) Journal
    Mosix won't migrate any processes that access local files, share memory, etc.. So in practicality a mosix-based application server wouldn't be terribly useful.

    It would be pretty cool, though.
  • NX isn't so much thin client as it is remote desktop over slow connection. Think connecting from home or other slow connection to your work computer and give it jobs to do. While this application may lower bandwidth for existing thin clients. Its not the real drawl.
  • Ooh, aah (Score:1, Informative)

    by Anonymous Coward on Tuesday August 31, 2004 @03:08PM (#10121421)

    ...into a 40 KBit/sec modem connection without losing responsiveness for the user experience.

    1996 just called to say "Thank you".

  • Re:How does it work? (Score:5, Informative)

    by be-fan ( 61476 ) on Tuesday August 31, 2004 @03:09PM (#10121440)
    NX is a compression and caching layer on top of the X11 protocol. It takes the basic X protocol and performs compression of protocol requests, caching of server responses, compression of images, etc.
  • by slittle ( 4150 ) on Tuesday August 31, 2004 @03:22PM (#10121551) Homepage
    Um... remote desktop client and server is definately in XP Pro (along with remote assistance). Of course it's only good for one user at a time (I assume this is an artificial limitation). What comes with the Servers is likely the full dealie that allows multiple concurrent desktops.
  • Re:How does it work? (Score:5, Informative)

    by Abcd1234 ( 188840 ) on Tuesday August 31, 2004 @03:22PM (#10121555) Homepage
    It works at the X protocol, rather than frame buffer level, which allows it to perform optimizations that VNC cannot. It also doesn't require a special graphical client... NX acts as an X protocol proxy, so your remote app displays locally like any other X application (as opposed to being contained in a separate desktop within a VNC session).
  • Re:How does it work? (Score:2, Informative)

    by Alien Being ( 18488 ) on Tuesday August 31, 2004 @03:24PM (#10121564)
    here [gnome.org]
  • by PythonCodr ( 731083 ) * on Tuesday August 31, 2004 @03:35PM (#10121675)

    ... or am I the only dinosaur who remembers these?

    GraphOn made this really sweet line of X terminals that allowed you to split the X server between the remote workstation server and the the display/mouse/keyboard. I was lucky enough to have one of these at home, and it was very zippy ... at 9600 baud I could run an X display that was darned nice to have a full X display at home while my VaxstationII sat at work. Later versions used better compression and were even faster and more responsive. They used all sorts of tricks with save-unders, display lists, and mouse-overs to keep the actual line traffic as low as possible.

    Granted, that was the late 80's, and X was in its infancy and clients weren't as feature rich as they are today (The web? Oh ... that thing that's going to replace archie, wais, and gopher...), but it worked just fine for what we used them for. Even at 2400 baud, you could use 'em, but you really wanted at 5400.

    Ah ... those were the days, when you could have a 12" X display at home ... 17" if you were really, really lucky. And they screamed at 19.2k! :-D

  • NX is to VNC (Score:5, Informative)

    by Julian Morrison ( 5575 ) on Tuesday August 31, 2004 @03:52PM (#10121838)
    ...as X is to frame-buffer.

    VNC runs an app remotely, displays it remotely, and sends bitmap movie of the display actoss the network. It can't scale, because the server has to do 100% of the work, and because sending bitmap diffs is bandwidth heavy.

    NX runs an app remotely, displays it locally. Only the unavoidable parts of X protocol travel over the network. It can scale well, because the server only does the bit-crunching; the "thin client" draws the display.
  • by bluekanoodle ( 672900 ) on Tuesday August 31, 2004 @04:00PM (#10121908)
    Not quite. Don't forget the TCO. It's alot easier and quicker to maintain and update a a properly setup thin client soluton serving forty nodes then 40 commodity boxes.

    I switched my company over to citrix and we ended up saving alot.

    1) I could use our legacy pc's in a locked down state as clients. This avoided having to buy new pc's just because our accounting app needed a faster processor.

    2)with centralized administration, we were able to avoid having to hire another staffer to handle support calls.

    3) When a piece of hardware dies, I can replaced it with a QUALITY thin client appliance for a less then it would cost for a QUALITY commodity box. Sure I could buy cheaper no name hardware, but I wouldn't stake my job on it.

    4) Our customized software does not need to be rewritten for different platforms. Doesn't matter if the client is running Windows, OS X, Linux or an embedded OS. they work exactly the same on each platfom. Not kind of the same, not sort of the same, but exactly the same. This saves on training the monkeys, I mean end users.

    We can also provide secure remote access to our data without worrying about whose using what license, and whether their offsite machine is compromised.

    At our current growth rate, we save almost 40% with thin clients over commodity boxes. That's not some number pulled from a marketing whitepaper, that's an apple to apples comparison from our department budget when we looked at both scenarios.

  • NOT KDE (Score:5, Informative)

    by ajs ( 35943 ) <{ajs} {at} {ajs.com}> on Tuesday August 31, 2004 @04:22PM (#10122108) Homepage Journal
    Let's be clear. This is not KDE. This has nothing to do with KDE, any more than KDE having an AIM client ties AIM to KDE.

    NX is not toolkit-specific, it's just a way of compressing the X protocol for displaying applications over low bandwith connections.

    That said, the KDE folks are talking about "integrating NX" into their KDE application framework, which would presumably mean having desktop tools that make the use of NX more convinient, and perhaps wrapping some of KDE's out-of-band data into the NX protocol (such as inter-application communication).

    This is all good, but people are missing the mark if they think this is a special way of moving KDE (that is, Qt) widgets across the wire. It's simply not.
  • I'm pretty sure the parent is BS or I just can't read what its saying. NX takes the X protocol and uses various caching and compression methods to make it more efficient. Unlike VNC which essentially takes a picture of you desktop and sends that, so its easy to see why NX works so much better. It is desktop environment anogistic more or less The client and whatnot I think are written using KDE widgets for the config menu, it uses artsd for sound. The folks developing the Free version are KDE people, thus its under the KDE category. But the server certainly doesn't know anything about KDE or Gnome or whatever, it just deals with X.

    X when using xeyes, xconsole and twwm might be a quick bandwidth-efficient drawing canvas... but it isn't with any modern program, thus the need for something like NoMachine.

    Why do you want to mix KDE and Xlib? Folks developing KDE don't even use Xlib, they leave that up to Trolltech. The only program I can think of thats still developed (sure there are others) and uses Xlib is the mplayer GUI, and I think everyone accepts its a POS, it mixes xlib and GTK last I heard. I just use mplayer from the console, sometimes with one of its KDE frontends.
  • Re:How possible (Score:2, Informative)

    by IvoryRing ( 1708 ) on Tuesday August 31, 2004 @05:03PM (#10122528)
    I'm going to give you the benefit of the doubt and assume you can't really see any way this can work:

    • Image representation that is more space efficient than the source. For example, someone uses 2000x2000 GIF file but sets the size on the IMG to be 200x200 (There are people that do this to 'precache' in case you want to look at the full sizes - no it isn't very helpful, but it happens) - resampling that down before sending it will send a lot less data. Also, on a page full of JPGs, if I am willing to waste CPU cycles, I can always recompress them to lower quality. I may, as the viewer, be willing to make the quality tradeoff, but others on a full speed connection don't have to suffer with it (as they would if the page author down-sized)
    • Bloated HTML. There can be tons of junk - either intentionally (think spammers attempting to get around word matching) or accidentally (certain HTML writers are really much more verbose than they need to be - for example, explicitly listing out every option to a tag even when the defaults are what you want; also it isn't unknown to see two or three different blocks of scripting to handle different browsers)
    • Significantly long pages. If a page contains 30 screenfulls (yes, poor design, but that doesn't mean it doesn't happen - remember that you have no control over the source) but everything I need is on the first two (or first and last), there is no real reason to send all 30 pages to me.
    • Other reasons where the source material is significantly more data than the resulting rendered text
    Obviously this doesn't always work, but in many cases it can work very well.
  • by Anonymous Coward on Tuesday August 31, 2004 @05:38PM (#10122842)
    Rich,

    If I had a nickel for how many times I need to admonish others that I am not trolling, I would donate all those nickels to X.org.

    First, KDE needs Xlib to connect to an X Server. KDE has graphics paths to Microsoft's GDI as well as X11. KDE doesn't have a rendering path directly to anythin outside of Microsoft's GDI. What I was trying to say is that KDE (and the same to be said for Gnome) is limited on Linux environments by the X Server. What you and I will slowly see is a reversal of technologies by the dominant *Desktop environments to establish a local API to access the canvas (think graphics hardware) directly and not needing to move through Xlib on the network datalink.

    The methodology that I am aware has already discussed this has been readily available in the Linux kernel as the "framebuffer" graphics modules and an alternative linux-only implementation known as DirectFB [directfb.org]. At the DirectFB project's homepage, there are many sub-projects. DirectFB is the framebuffer drivers where currently GNOME and generaly anything using the GTK+-2.x (and GTK+-1.x Iirc) can use a framebuffer with a driver-based unnetworked window-managing system with window transparancy; ie everything KDE and Gnome Desktop desire without needing to move through Xlib in the final packet session output to the X Server. It is all done without the X Server. Further into the DirectFB project website you will find a X Server that *runs* on the framebuffer; tricky thinking, that I suggest to you that this X Server is interfacing its windowing environment regulated by the DirectFB's natively-encoded window manager; XDirectFB [directfb.org]. As much as I dislike linking and using enterntainment software to discuss the innovation in DirectFB's many subprojects; I do reveal to you that there is even the project DirecFBGL [directfb.org] demonstrating using the Direct Rendering Infrastructure [sf.net] without a X Server and in the Framebuffer provided by DirectFB. Quake3, accelerated, in a Framebuffer [directfb.org], I apologise for only having posted an example of entertainment.

    K NX is the prequel to DirectFB; NX server tries to keep X11 and KDE tightly bonded because KDE has no rendering path through anything but a X Server and Microsoft GDI. I need not say more.

    Despite you labeling me as a troll, I forgive you. I've made mistakes, and one of them was not to secure "SlashdotTroll" from the hands of debilitating users to post pornography and slander.

    HTH,
    -SlashdotTroll
  • by Espectr0 ( 577637 ) on Tuesday August 31, 2004 @05:54PM (#10123014) Journal
    4 entries found for infer.
    1. To conclude from evidence or premises.
    2. To reason from circumstance; surmise: We can infer that his motive in publishing the diary was less than honorable.
    3. To lead to as a consequence or conclusion: "Socrates argued that a statue inferred the existence of a sculptor" (Academy).
    4. To hint; imply.
  • Re:Belongs in SSH (Score:4, Informative)

    by Effugas ( 2378 ) * on Tuesday August 31, 2004 @07:45PM (#10123975) Homepage
    Yeah, but this is OpenNX encapsulating SSH, rather than SSH encapsulating OpenNX. The latter is, architecturally, the most simple and straightforward way to deploy NX.

    --Dan
  • by agoliveira ( 188870 ) <adilson@adilson. ... t minus math_god> on Wednesday September 01, 2004 @04:11PM (#10131913)
    I'm a NoMachine developer and I can say that we (and this includes NoMachine's top managemment) praise and help the FreeNX initiative. Actually, they even have access to our internal mailing list where we discuss the latest plans.
    We believe that FreeNX will help us in the future, not undermine the company.

"I've seen it. It's rubbish." -- Marvin the Paranoid Android

Working...