Slashdot Mirror
Proxy Servers Lighten Up X
An anonymous reader writes "LinuxDevices.com is reporting on a compression and differential proxy scheme for X that makes it practical to xhost rich applications like Mozilla or a whole UNIX desktop over a 9.6Kbps connection (think cell phone with GSM modem). The company developing NX has a neat test drive set up -- and it is way zippier than VNC. There'll be a paper about it at the next LinuxKongress in Saarbrucken, Germany, and a call is out to OSS programmers to build on the GPL'ed NX library."
Sounds great, though how much use would conventional and current ways of treating X applications scale down to a relatively tiny mobile screen? Seems like there has to be some changing of the interfaces of the software as well as the nuts and bolts behind the scenes.
Hmmmmmmmmm......yup, they're definitely prepared to be a
1. No sig. 2. ???? 3. Profit!!!
just how useful will mozilla be to me on my cell phone with its miniscule display, or any other full blown regular GUI based PC app for that matter?
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I for one welcome our new X overlords
(Sorry, but I'm not able to read the PDF right now, and there doesn't appear to be a whole lot of technical info on the web site.)
So can anyone address how this new product is any different or better than Low Bandwith X? LBX is also a proxy server that caches a lot of information local to the application cut down on traffic across the slow link to the actual X server. I've used it to run programs like XEmacs and XTerm across 56K links and it works very well. It's less useful at graphics-intensive programs like Gimp.
I thought the only one was /usr/bin/fortune or have I missed something??
How fast is citrix? Because on a LAN X is pretty snappy, almost like local. Or is citrix very good on low bandwith networks?
Don't forget tarantella, from our friends SCO.
Pretty decent performance, much better than plain X. Besides, if you're stuck on a windows machine you don't need to get a (usually buggy) X server installed locally.
www.tarantella.com
What would be cool also would be if you could use X over a single connection from your local machine to another, so you can use it from an rfc1918 address behind NAT to the "server", without having to set up tunnelling.
And how to kick it off right from a gdm login?
Government of the people, by corporate executives, for corporate profits.
I had no idea the KDE project was behind this.
Isn't the X client/server built to naturally support being used transperantly via the network??
(like other stuff in *nix that are client/server instead of API)
Citrix is pretty fast (I use the Linux Citrix client on an OpenBSD box to work on a machine halfway across the country) but it caches a huge amount of data locally. Of course that's the tradeoff for the speed you see. If speed isn't that big an issue stick to TightVNC, the price is right :)
Trolling is a art,
One simple answer: ssh.
Doesn't matter how you connect to the machine that'll run the program, it'll tunnel all your X stuff over the existing ssh connection, so you don't have to worry about anything. I was stuck on Windows machines sometimes with an X server, and putty handled X tunneling perfectly. Just a checkbox to click and then it worries about the rest.
Stop messing with "export DISPLAY=xxx.yyy.zzz.aaa:0" already...
Maan
Not anymore.
Let the server errors commence!
What part of "shall not be infringed" is so hard to understand?
But can anyone comment on the quality of connection with a GSM phone attached to a laptop ? I love my GSM phones but I'm not sure I would trust the quality of connection to try doing something remotely if there was a risk of things going pear shaped if the connection dropped.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Network transparancy is one of the shortcomings of X11 -- I mean, who would ever use this? They ought to figure out some directfb stuff for the cell phone or something. /typical x-hater statement
This is cool -- and one of the reasons why X is cool. While it's aimed at mobile devices, it'll breathe new life into old hardware, too. Like my SS10, for instance -- it's too slow to run much anything other than NetBSD and an X server. But it runs remote apps fine. It could even make my old Mac Quadra useful as a basic X console.
Just what X was made for I thought.
First I tried straight X (over ssh -X -C of course). This is on a 256k upstream DSL link.
The performance was pants. Really bad. At first I thought I must be doing something wrong. To be honest, Gimp wasn't too bad, but a Gnome 2 application like Xchat2 was really slow. Menus would take an age to display.
I tried looking around for a low bandwidth solution, but couldn't find any free ones.
I've ended up using VNC over SSH. It's much better than straight X. Plus it's got the added advantage that I can just leave the application running, and connect to it from anywhere.
With X, there is no easy way (xmove was impractical) to leave an application running, and move it between desktops.
-- Hulver's site
The mobile phone screen angle is a red herring. The really great thing about this is that it massively reduces the bandwidth required for running X over the network and it also reduces latency. The issue is that X consumes a lot of bandwidth. In some cases, if the bandwidth is available, X will use up to 10 Mbps to display a remote application screen. This is excessive and limits the use of X. Running X through ssh with compression enabled helps tremendously but can still consume 220Kbps. VNC offers similar 220Kbps or less performance to X through ssh but has much higher latencey so, it's not perfect either.
This new NX proxy is claiming 9.6Kbps X applications. Even if it doesn't come close to delivering that and is closer to 28Kbps or even 40Kbps it is still a massive improvement over X and ssh or even VNC and it now falls in line with the Citrix ICA protocol. It also apparently adds some of the Citrix features that X was missing but, the reduction in bandwidth alone is a tremendous improvement. You don't have to use it on a mobile phone and chances are I never will.
So how is this different from what DXPC does already? Faster, better? Niftier logo? http://www.vigor.nu/dxpc/ I used dxpc years ago when I had a slow connection. Worked great, as soon as you figured out the tricky bits when combining with SSH and tunnels over multiple nodes. TA (no connection with dxpc other than as former user)
UK UNIX User Group
Linux Conference 2003
The NX Project
What is NX?
- NX is a remote desktop system based on X-Window
- Adds features to X-Window usually found in proprietary systems like MS RDP and Citrix ICA
- Makes possible to run contemporary Unix applications over the Internet
- Compresses the X protocol by an average factor of 50:1 and more
- Allows users to work comfortably on 28.8Kbps or even 9.6 Kbps modem connections
- Reduces X protocol round-trips nearly to zero
- Implements image streaming algorythms to reduce the perceived latency
- Is able to translate RDP and RFB foreign remote desktop protocols to X
- Runs these foreign remote desktop sessions faster than their native protocols
- It integrates with SMB to provide access to the client's file systems
- It integrates with ARTSD and ESD to allow media playback
- Adds server management tools to handle X, RDP and RFB sessions run by users
- Architecture is designed to distribute the server workload between multiple nodes
- It leverages SSH remote execution capabilities to avoid the need to run a new network server
- It is able to encrypt and protect the network traffic by tunneling the connections through SSH
- Server is intended to run on any Unix OS
- Client runs on Linux, Windows, Solaris, Mac OS/X, Sony Playstation/2, MS Xbox and embedded devices like HP/Compaq iPAQ and Sharp Zaurus
- NX core components and X compression libraries are released under the GPL license
- NX client GUI (nxclient) and the NX server manager (nxserver) are commercial software
- The NX client-server protocol is open
- A library handling the client-server protocol and a compatible command-line NX client have been released under the GPL license
- NoMachine has publicly offered its help to let OSS developers build a free implementation of both the nxclient GUI and the nxserver NX System Architecture X NX "protocol" (internet, modem) Local X display Local NX proxy system Remote NX proxy system Remote X application Windows Terminal Server, XP Prof. (Tight) VNCServer nxagent (based on Xnest) nxdesktop (based on rdesktop) nxviewer (based on vncviewer) RDP X RFB
What features are missing?
- X session persistence and reconnection - Better support of RENDER extension - Better support of X applications in seamless mode
- Better support of SMB file-sharing and printing
- Seamless access to client's peripherals and devices
- A new multimedia architecture with native streaming of media formats
- Better integration with Unix and Windows desktop environments to allow point-and-click remote execution of applications
- Better server management tools, including a Web administration interface
- An open API to let customers and developers to write server extensions What NX would like to become?
- A convenient way to let users of mobile phones and other thin devices to get access to complex, rich applications
- A server infrastructure by which people can easily run applications regardless they reside on the local machine or a remote server
- A peer-to-peer computing environment where users can easily access computing resources, like storage and printers, on any server available on the Internet
- A step in the direction of the "network desktop" envisioned by many
One simple answer: ssh.
you've got that right...but how does one ssh to their phone?
We're like rats, in some experiment! -- George Costanza
Keith seems to believe that the solution to X performance issues lies in the clients; and in the long run this may very well be true. However, NX takes the old proxy/agent paradigm pioneered by LBX and dxpc and does something useful with it finally.
Always the problem with these things. ssh display forwarding and lbxproxy can both reduce the bandwidth used by X11 but both increase the latency, sometimes to unacceptable levels.
On the corporate LAN we have 100Mbit switched and haven't noticed bandwidth being a problem. We have however noticed that both lbxproxy and ssh require more CPU in order to perform compression and buffering which *can* be a problem on a shared server if the number of concurrent sessions it can support drops by 20%.
I guess if you want X to your phone then it could be an issue, but that's a fairly niche market.
Government of the people, by corporate executives, for corporate profits.
I'm curious as to what network layer this ssh tunnelling is done. I'll give it a try next week, I was already in the throes of setting up a vncserver, seemed easier.
I've playe with this awhile back and I must say it was nice. Has removet printing support and file transfer (if I'm not mistaken). THE two things that the VNC original AT&T people didn't put in. And it's too bad, cause if they had, we'd all be using it. But anyway, the fact that some of this software is OSS is kinda nice. A nice gesture from what seems a nice company.
uummm and graphic specific compression method, what's the command line option again ?
#include "coucou.h"
Did you RTFA?
NX places a caching proxy server on either side of X's client-server architecture, reducing network traffic to differential transfers of whatever is not already cached. The company says programmers rarely optimize X applications for low throughput on the X client-server interface, resulting in many needless "round-trip" data transfers that NX can largely eliminate.
So instead of taking the whole X session and cramming it over ssh (even with compression) you cache the majority of it and just pass the deltas.
It has ssh capability so I imagine you can tunnel it but you would still be tunneling a LOT less traffic.
Citrix and X are pretty comparable on the LAN. Citrix is much faster, however, over lower bandwidth links.
You don't have very much experience working in a corporate Unix environment, do you?
Who would use it? Every corporate I.T. dept on the planet which has Unix or Linux installed somewhere.
We have 400 hardware and software engineers who's only access to Unix is a Gnome login. Everything they do is remote to arrays of rackmounted Unix boxes. It saves a fortune every year.
Government of the people, by corporate executives, for corporate profits.
Depends on the phone!
Basically, data over GSM is a bad idea. The max speed is 9600 kbit/s. There are other alternatives, such as HSCSD (High Speed Circuit Switched Data) which will provide 56.6kbit/s, and GPRS (General packet Radio Service) which will give up to 384kbit/s (if using EDGE). Then, we have the 3G standards, CDMA2000 and WCDMA, with up to 2Mbit/s (close to the base station, and only if you're almost alone in the cell...) While the 3G isn't much available, GPRS is. Why you'd like to use the GSM for data is beyond me.
I thought it was free.
Did I read this correctly? A project aiming to allow rich interfaces remotely is going to use a crippling web interface for administration? *boggle* I hope by "including" they mean "it'll be there, but you don't have to use it and we'll have something a tad more functional".
Note to self: pasty-skinned programmers ought not stand in the Mojave desert for multiple hours. -- John Carmack
Another product that's been around for a while and works pretty good is Differential X Protocol Compressor. How does this new product differ?
I've done this before on MacOS 9 with MacSSH and MI/X ppc, and the performance was *really* bad. Far worse than you would expect. I ran it on a 250 MHz G3 (in a 7500) over a local 100mbit lan. The same hardware running Debian was snappy. I don't know whether it was MacSSH that was the problem or MI/X.
When initially switched and now it saves nearly a hundred grand a year.
We don't do transactions... HTH...
Government of the people, by corporate executives, for corporate profits.
I dig network transparancy. I was just getting the typical anti-X trolling out of the way. :-p The fanboys who think that everything should work exactly like Windows, but be free (as in beer). If you need to, you buy a KVM, etc. etc.
But some compression for low-powered devices could, once again, make old hardware useful, in addition to having the use on the mobile devices.
You are right when you say our friends from SCO. Those guys got out before everything shat. I just wish one would step up and cut the fud.
This is great to hear. Up till now, even though X has had remote display abilities built-in, it has not been at all practical to replace something like ICA or even RDP. The next step though is to get thin client manufacturers (maybe neoware's linux-based models?) to support this protocol natively. The article doesn't mention how large the libraries required for NX are, but hopefully it is something that could be added to existing thin clients.
Along with that step, it would be great to see "shadowing" support, which has been one of the killer support features of Metaframe (and now TS). The neoware devices have built in tightvnc, but it is not quite as good as ICA/RDP shadowing (NX probably wouldn't have been necessary if it was)
-Mark
Tarantella is the real SCO.
Not to be confused with Caldera, the SCO that has the ongoing pump-and-dump and extortion scheme.
> Why you'd like to use the GSM for data is beyond me.
If they make X faster for GSM, I bet it'll turn out faster for other connections as well.
A guy here mentioned that X was slow over his 256 kbit dsl conection. With the work of these GSM guys, it will probably improve dramatically.
And watch your phone go into meltdown when the extra load from the proxies make the performance drop by 20%.
Government of the people, by corporate executives, for corporate profits.
ssh -CX user@host
Where -C does compression and -X enables X-forwarding.
-C also works for scp.
HTH. HAND.
X-sessions crammed into your phone which is, in turn, crammed into your ass.
It's a slashbot paradise!
Citrix MetaFrame/ICA.
Citrix is traditionally known for connecting X to Windows desktops, but they make a product that compresses X11-to-X11 as well.
The good news? It kicks butt. You can feel a lag, but it works far better than anything else I've tried in the speed department. In particular, Acrobat reader renders VERY quickly, and that program is a pig with bitmaps.
The bad news? It kicks butt by compressing the event stream... in a lossy manner. I have seen all sorts of minor glitches, such as menus opening up underneath their parent windows. But some programs are unusable - the Sun Java machine is an example - certain dialogs require a triple-click to select something because somehow Citrix consumes the other clicks.
The bottom line? If you want a solution for the office environment, then this is worth looking into. (Not free, however.) When evaluating, check ALL of your apps to see how bad their lossy event handling will bite you.
Terminal server (and Citrix before it) have always been superior to X and VNC. It's nice that OSS is finally catching up to the commercial offerings.
Not anymore, they don't.
There is no sig, there is only Zuul.
I don't know about NiftyTelnet, but if you're on OS X, the plain command line ssh (openssh) should do it. If it doesn't work at first, try ssh -X to force X tunneling.
SSH tunnels at the IP level and can tunnel any connection. It sets up a listening socket on a specified port on one side, and repeats everything it hears on that port to the other side. X tunneling is just one specific application of this feature.
Gotta love ssh...
Maan
So instead of taking the whole X session and cramming it over ssh (even with compression) you cache the majority of it and just pass the deltas.
Wow. VNC.
Wow, not only are they running from italy, they are actually taking NX to court? I thought that truly intelligent AI was years off.
Contact Me (got tired of viruses emailing me).
and just to add, this stuff belongs in the toolkit.
and they are working on that in gtk, which is known to have excessive roundtrips, which will kill performance.
I know nobody likes to talk about p... pr... proprietary applications on Linux, but in reality, commercial applications will an important part of Linux's future if it ever takes hold on the desktop. Could this functionality, delivered to any X application be perceived as a reason NOT to develop commercial applications for linux?
Citrix ICA has a very stringent license-management system, allowing licensed applications to be served remotely only to licensed clients, and only to a limited number at a time. This is important for software publishers... they don't want groups of people to buy 1 license and serve it for all their friends.
Why hasn't Windows implemented functionality like remote X applications? It's not like it would be hard for them, although you know they'd never get it secure. Imagine if ANY windows program could be served to other people indiscriminately. That would kill their licensing scheme. A perfect example of why proprietary software development works against the needs of the consumer. Windows users haven't demanded Windows network transparency because they either don't know it's possible, or think Terminal Services is "OK". (haha, good one). There's a reason why Terminal Services will only work for 1 desktop at a time.
I have a feeling that the network-transparency of X is already a barrier to many commercial applications. Now this proxy server thing is going to make it work better and faster, even with higher latencies/lower bandwidths? Not that it's a real problem, but if you were wanting commercial apps like Adobe, Macromedia, sound editing, video editing, 3d redering, etc. to come to Linux, maybe it'd be worthwhile to think about license protection mechanisms for X applications...
-3Suns
~~~~
The Revolution will be Slashdotted
Hmmm . . . So how exactly does this work with XDMCP?
There is a free solution included with almost every X server -- lbx. If you want, you can even use lbx and tunnel it through ssh, although that doesn't improve things TOO much, as you add latency.
To enable lbx, log in to the remote machine, make sure $DISPLAY is set correctly and execute something like this:Adjust
Make sure that your X server (on your client) has lbx extensions enabled. If you use Hummingbird Exceed, for example, it's not enabled by default.
Regards,
--
*Art
X11 has had dxpc, the "Differential X Protocol Compressor" for many years. Yes, it works. Of course, LBX is now built into the server, although dxpc seems better. JCraft has a Java implementation of dxpc.
At home on my cable connection, I've tried to use X to run apps on my Linux machine at work (Windows, because I have to use the Intel Shiva VPN client or whatever the heck it's called now - it doesn't use IPSEC)
I tried it both ways - regular and with LBX, and no matter how I do it, it's *slow*. Really slow. It's probably not the bandwidth, but I suspect it's the latency that kills. Naturally VNC works fine. And of course, doing the above on the local net at work is just fine too.
I was wondering if I was doing something wrong, or if there's something I can do to optimize that connection. I'd really like to use X remotely this way, but I haven't found a way to do it that yields acceptable performance.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
One simple answer: ssh.
You use the word "simple" in a way that is strange and confusing to us Earth people.
I SSH phone users all the time. Not only is it easy to do, but fun and rewarding as well.
First I start by holding up my index finger in front of my lips, then...
You see? You see? Your stupid minds! Stupid! Stupid!
I have broadband cable at home, but using mozilla through a remote X connection stinks. It usually hangs if I accidently ever drag and drop a email message. For some reason, the little D&D icon causes a great deal of problems in my setup. Plus, windows take forever to draw. Other stuff seems a ton snappier.
Anyone else have this problem? It happens for a couple of my linux home boxes.
Ed
I realize VNC is cross-platform and hooks into the OS in fundamentally different ways, so this is not really a fair comparison. But under term. services both machines are much more responsive than under VNC. Linux needs a remote access scheme that works as well.
Except that vnc cheats, and uses change tiles from the screen, NOT of each individual window, and definently ignores the way events interact, except at a more basic level. You'll notice this effect when you're seriously lagged. it'll waste time redrawing linearly, instead of letting the applications group events into batches.
:)
That's why vnc tends to emulate an entire desktop. Things that are infront, behind, in focus, or whatever are drawn to a buffer on the remote server, and updates for the buffer are sent, regardless of wether the update is just a redraw of something that had been seen previously, but hidden.
Now, in case you haven't noticed, X operates differently to this, individual applications can mask out the events that they want, and ignore redraws selectively, although, quite often, as someone else mentioned, programmers rarely take this into account, and redraw more than they need to.
A caching proxy for X will eliminate redraws that AREN'T different, and potentially, recall changes that are the same as they were some previous time. If the proxy understands the X protocol, you can work at the window/event level, not at the screen level, and keep within the normal X paradigm.
Not only that, but windows can still only select the events they care about, and the client side will react accordingly, as you want them to, as you GET with Citrix, where you can run an individual app without a full login shell, with the added bonus of lower bandwidth usage.
Bring it on, especially if it maintains a progressively decaying backbuffer it can use to recall chunks.
ashridah
VNC is still a lot less efficient than a protocol that actually knows duplicates window messages locally.
Instead of having to poll every single time you move a window, X connections only do it when something changed (ideally, and it looks like that is what this development helps guarantee).
I have VNC and X accessible through SSH tunnel, and I use X preferentially. Just makes sense.
And yes, you can forward an entire desktop X session.
Er, what's with SMB and ssh support in this
product? Does it proxy those protocols too?
I don't see any point in proxying ssh.
With X, there is no easy way (xmove was impractical) to leave an application running, and move it between desktops.
In what way was Xmove impractical? I run it on the remote server and have xmovectl clients to jump me around when I need to drag X applications around with me as I move IP address. It works fine.
On the other hand, if anyone can point me at a way to secure Xmove so that I am the only user who can muck with my apps, that would be good... I'm not convinced that Xmove was built with security in mind.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
when you fix HuSi!!
Infidel!!
Wouldn't it be easier to just use the Brightness control on the monitor?
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Even if the client and server are on the same machine, dramatically reducing the amount of data sent between them and still keeping it working well - that surely can't hurt, and might even make the desktop more useable. (Right...?)
I believe NCD Xterminals have had a similar compression technology for many years. I remember using them on 19200 baud modems. Latency was the big problem but throughput was good. I can't imagine anyone still using a 9600 baud modem, especially someone serious enough to want to use X remotely. 128kb is plenty to use raw X and any broadband connection is going to be faster than that, but if you are remote and on a modem this might be a good option. Marc
In Server 2000, I guarantee you can have multiple clients on the machine at once via Terminal Services. We do it all the time at work. Open up Terminal Services manager, you'll see there's a sessions tab.
There is a finite number of slots available, but that's configurable... And you can certainly have different users logged into the same machine at once.
Admittedly, I have only used the windows version of VNC, but I'm unclear as to how it could allow multiple sessions, since it seems to just mirror mouse/keyboard activity (eg, when I use VNC over my lan I can see the cursor moving on the target machine. this is not the case in terminal services -- users in the background are transparent, unless you're looking at the management tool).
Don't get me wrong, I love VNC -- windows won't let you run terminal services server on win2k pro, so I use VNC quite a bit. But it definitely feels a lot clunkier than terminal services to me.
Fugu for OS X is quite a nice open source app for doing SCP / SFTP and also setting up SSH tunnels. I use it to connect to my home (linux) server from my G4 at work.
> they are actually taking NX to court?
> I thought that truly intelligent AI was years off.
Corporations can sue. Darl McBride can sue. Your proposition that entities must be "truly intelligent" (or, in fact, intelligent at all) is wildly off-base. Therefore, your conclusion (that truly intelligent AI is no longer years off) is invalid.
Do daemons dream of electric sleep()?
"being remotely displayed here suing NX"
Wow, brand new and being sued already. Who told SCO about these people, then?
Chuck Norris: Socialism == a thousand years of darkness.
Provision bandwidth for work and home from the same ISP. Don't let your X packets hit the internet. 1.5 mbits @ 5ms is plenty fast for darn near _any_ X app, even without LBX. And xemacs19 positively *flies* -- it's hard to tell I'm not at my desk. :)
Do daemons dream of electric sleep()?
Werent these people talking about this a year or so ago?
Not much came out of it then, from what i remember...
But its a nice goal to have.. RDP protocol is hurting us RFB/X11 people in the dialup department...
---- Booth was a patriot ----
This explanation is a bit vague, enough to be somewhat inaccurate. If you execute ssh from the Terminal in OS X, X forwarding will not work no matter what you do. You have to run Apple's X11 application, then run an Xterm, then do 'ssh -X wherever'. That is how it is if you are just using the X11 implementation Apple provided you with, not if you installed it yourself. Dunno about the latter situation.
I do it this way all the time, very useful.
There is a reason they didn't include it.. it was NOT NEEDED for what they were doing. They needed platform independent remote view/control. Nothing more, nothing less.
*ALL* modern operating systems have native file transfer mechanisms.. there is no need to bloat out something like VNC by re-inventing the wheel and shoving it in there..
Integrated encryption.. would be useful, unfortunately.. ( shouldn't even need to be a consideration, but in today's sick world it is. )
---- Booth was a patriot ----
This is the same exact principle that it ran on.. and it ( sadly ) didn't take off..
Is it even being developed anymore?
( its at least free and open.. NX wont be.. )
---- Booth was a patriot ----
I can't imagine anyone still using a 9600 baud modem, especially someone serious enough to want to use X remotely.
GSM data? GPRS and friends have somewhat more speed, but not everyone has upgraded their phone...
Everyone who makes generalizations should be shot.
Port forwarding via SSH is a bit one sided, though.
You can take a local port, and forward it to a remote location, but you can't forward a remote location to local. At least, not "openly". (only from localhost)
This means that you can take a connection inside a local network and tunnel out, but you can't use SSH to tunnel through a firewall outside and get a connection back *in*.
I sent in a note to the SSH dev mailing list and they told me that it's not a bug, that they want it this way...
Why couldn't this be done, and then toggled based on a setting in the config file?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Didn't even notice it was Hulver until I saw you mention HuSi.
Don't waste your time trying to get NeoWare or NCD or Wyse or any of these Windows Terminal companies to pay any attention to our need for X terminals. The one company that you should buy your X terminals from is Igel. They even have a new wireless Smart Display (read X terminal) coming soon.
X is open, X is free, X scales, X costs nothing, and these are just for starters
Citrix & WTS are proprietary, are closed, do not scale, are VERY expensive, and these are just for starters.
+ WTS allows multi user. (2 connections before you need to buy licences)
+ VNC does not allow multiuser on Windows.
Citrix is currently a value-add product for Windows Terminal Server.
ssh -h
-L listen-port:host:port Forward local port to remote address
-R listen-port:host:port Forward remote port to local address
These cause ssh to listen for connections on a port, and
forward them to the other side by connecting to host:port.
-D port Enable dynamic application-level port forwarding.
Why doesn't -R do what you want? I've tunnelled a port on an external webserver through to an Apache webserver behind the firewall using SSH before.
Get your own free personal location tracker
Try launching xterm remotely over SSH/DSL. It will display 20 times faster than gnome-terminal does locally.
I strongly suspect the problem is the applications resort to a lot of synchronous function calls. And I suspect much of this is hidden in the widgets, which keep querying the server: "My container is asking how big I am; how big am I?"
So I would direct my complaints to the designers of the widgets: I should be able to set up a nested hierarchy of a hundred widgets without playing ping-pong with the server for minutes.
Well, there are bands of HAM radio that allow 9600bps connections. If I could get an X display over a handheld transceiver running to a laptop I would be very, very happy.
Little Brother, watching the watchers
Despite broadband and etc, I have noticed that SSH'ing to my CS servers to run X can be very laggy.
.uu.net :D)
I would like to see some of the remote latency decreased, maybe this technology offers a way to do it? SSH supports ZLib as a compressor, but I've noticed little or no effect on latency over my 1500kbit DSL with pretty good ping to many game servers. (It's MCI Worldcom, yuck, but hey, it's cool to have an ip that is
Any idea if this is applicable for the *BSDs or Solaris?
It seems as though NX is adding the concept of state, beyond bitmap caching, to X11. By reducing round trips between the client and server, it eliminates unnecessary data transfer because something on the client side of the network is already aware of the state of the server and doesn't need to inquire about it.
Is my understanding accurate?
Do more recently designed network graphics protocols use sychronized state between the client and server? With gobs of memory easy to come by these days, it seems like this would be acceptable cost, where perhaps it wasn't when X11 was designed. Would a stateful, high-level vector api (higher level than cairo, even) be a useful extension to X11?
I suppose I'm not too threatening, presently, but wait till I start Nautilus
Out of curiosity, is there an easy(preferably free) way to extract the text from a PDF file. Heck, an editor that let you change the text would be even better.
;-)
Or did poor Mr. Anonymous coward retype all the text?
I know this is a little off topic so, if you had this ideal solution, could you run it remotely in an X session?
I thought Communism was a red herring! Get a Clue, man!
Weaselmancer
rediculous.
Try setting the DISPLAY environmental variable to :0 or whatever number it is. That's how it works on Linux and Fink's old X11.
Using a method of buffering output at both ends and transferring only changes across sounds a lot like the Rsync algorithm. It seems like using a buffer at both ends and rsyncing everything over ssh would be a natural way to approach this, are there any open source projects that have tried it?
My blog
If they could do in in hardware it would be ok. I'd love to have a cellular PDA I could access my home computer from and run x apps.
Give me Classic Slashdot or give me death!
Any news on an open source client? As soon as one is developed, I'm sure many more people will begin using it and, in turn, testing and experimenting with it.
Specifically, take a look at the "-g" option. Using the "-g" option allows other hosts to connect through your forwarded port. However, it only works with the "-L" option, and not the "-R" option.
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Wake me up in the year 3000 when it finally gets around to optimizing for realtime interactive 3D.
a new use for my 9600 baud modem!
Another reason to read at the "0" level. Is this a record, or what?
BTW The search results should be segregated by month not amout i.e September instead of "next 30 results".
This is a server configuration issue, I think. I use the OpenSSH client in OS X to connect to an SSH1-only server that lets -R listen globally. But I've also noticed some SSH2 servers that don't let you.
Here are some of my experiences with X and remote desktops:
My home setup has a LAN accessing the 'Net through a 1.5 Mbit ADSL line. An aging Linksys 4-port DSL router and a somewhat newer D-Link 4-port switch provide routing and switching services. The main X server is located on a Pentium 200 MMX, 64 MB RAM box running OpenBSD 3.2.
Software setup on the X server includes OpenBox as window manager and a semi-standard application setup (Opera, PDF Reader, Abiword, Emacs, etc), compiled and installed from the OpenBSD 3.2 ports tree with no modifications. LBX extension is enabled in X server settings, using defaults.
All computers, routers, switches, and cables involved in LAN are running at 100 Mbit. Latencies on the LAN from one device to another are typically around 1 ms.
The Pentium 200 X server is also used as a web server (Apache), DB backend (PostgreSQL), file server (Samba), time server (NTP), shell server (OpenSSH), and terminal server (2 VT52 terminals). Currently the machine also runs a proxy server (squid) which wasn't running during the first round of X server tests (inside local LAN).
Average load on the server is basically 0% when it is not being used, and about 60% if someone is using the console, has an X session running, is playing MP3s, and all other services are being used by one user at the same time.
For those that are curious, my server can currently be accessed from the outside using this URL (you should automatically be redirected to the server):
http://web.csuchico.edu/~il11/website.html
Now, the results of (mostly subjective) testing. Accessing X server from another OpenBSD 3.2 machine, using default settings, over LAN:
1. Response time - almost instanteous. I'd estimate lag to about 1/4 to 1/2 seconds, part of this to be attributed to the underlying machine slowness.
2. General speed - I could not see any difference whatsoever between working on the server console and accessing it remotely.
3. Stability - there were no problems during several multi-hour sessions.
I played MP3s, watched smaller MPEG movies, surfed the Internet, developed for my web-based DB tools, and generally programmed. The feeling was basically the same as if I was sitting on the console itself.
Next, the same testing, done from 11 time zones away, through a dial-up link 33600 kbps link, using XSecurePro 7.3 on Windows 98 machine a touch better then X server (Pentium 233 MMX, 96 MB RAM):
1. Response time - between 1 minute and 5 minutes. Basically you click on something, work on something else for a few minutes, then look back to see what happened.
2. General speed - worthless unless in case of extreme emergency. Everything takes 10x the time, at least.
3. Stability - no real problems, just slow.
Now, attempting to try the new NXClient 1.1.1.2, over same dial-up setup and connecting to their test server, here is what I observed:
1. Response time - between 10 seconds and 1 minute. Could be used, but it would be painful.
2. General speed - falls somewhere between totally useless and marginally tolerable if bored categories.
3. Stability - no real problems noticed.
Another difference I noticed is the fact that NXclient could not tunnel sound, while my LAN X setup could. XSecurePro 7.3 on Windows does not seem to have that option. NXclient is of course based on Linux and Gnome and KDE as desktops.
I haven't noticed any sort of load or increased latency on my LAN during any of the tests I did (even while streaming video from X server to another PC, while moving multi-GB files across to Samba server, and having 2 other PCs on the LAN involved in a hot CS game).
Basically, the conclusion that I am making here is the NXClient is not really useful unless you have at least a 128 kbps ISDN. Anything less than 256 kpbs DSL is probably not really smooth. At that speed, however, I could use my X setup with LBX from one side of town to another, using 256 kbps
Mark Twain's plan for the improvement of spelling
For example, in Year 1 that useless letter "c" would be dropped to be replased either by "k" or "s," and likewise "x" would no longer be part of the alphabet. The only kase in which "c" would be retained would be the "ch" formation, which will be dealt with later. Year 2 might reform "w" spelling, so that "which" and "one" would take the same konsonant, wile Year 3 might well abolish "y" replasing it with "i" and Iear 4 might fiks the "g/j" anomali wonse and for all.
Jenerally, then, the improvement would kontinue iear bai iear with Iear 5 doing awai with useless double konsonants, and Iears 6-12 or so modifaiing vowlz and the rimeining voist and unvoist konsonants. Bai Iear 15 or sou, it wud fainali bi posibl tu meik ius ov thi ridandant letez "c," "y" and "x"--bai now jast a memori in the maindz ov ould doderez--tu riplais "ch," "sh," and "th" rispektivli.
Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld.
I meant to say:
9k6 means 9600, not 9006. The multiplier takes place of the decimal point. 9600
= 9.6 thousand
= 9.6 k
= 9k6 bits per second.
Over a slow link, the faster a packet ends, the faster it can be responded to. If your dialup modem is using 1000-byte packets at 33kb/s, it takes 1/3 of a second just for each packet to leak out through or be sucked in by the modem, to say nothing of delays in any other hops or the possibility of getting a sucky connection (think 14.4kb/s). If you haul it back down to using 200-byte packets, that turnaround drops to 1/15th of a second, much better for interactive stuff.
The compromise is that more of your traffic will be packet headers and checksums, so your absolute bandwidth will drop slightly.
You can also throttle traffic slightly to reduce buffering and allow responses to come back faster, which may actually increase your bandwidth and latency (counter-intuitive as that sounds).
Got time? Spend some of it coding or testing
Just the text, ma'am.
Got time? Spend some of it coding or testing
This is the kind of technology that would make touch screen portable displays a usable reality. If I could use GSM to connect to my home/work servers from a truly lightweight touchpad screen think how productive I could be! EVERYTHING on the network literally at your fingertips no matter where you roam.
Maybe those electronic notepads they used for Startrek TNG aren't so far into the future after all...
"Straddling the sword of technology..."
The *client* is.. but it looks as though the server components are non distributable..
This is the same as it was last time these people came up in the news.
A orphaned client is sort of useless.. regardless if its free or not.
---- Booth was a patriot ----