Low-Bandwidth X

pinzari self-promotes with this: "What about running a full-featured X desktop on your Yopy? Or having a virtual Linux machine, running at your ISP site, being accessed by a TV or PS2? I know Slashdot has treated this more then once and I remember a really interesting thread a few months ago. I think that most of the reasons why nobody has taken this seriously is because nobody thought it was actually possible. Medialogic has just released MS1 of mlview-dxpc. It's a deep rework of the old DXPC which can really be used to run remote X desktops over the Internet, the way Citrix, Microsoft and SCO aim to do using proprietary protocols like RDP and ICA. mlview-dxpc is very preliminary but, in our opinion, it looks very promising. After all this hype about .NET and Application Service Providers, I can't forget X was born exactly for this purpose."

Comments

Re:How useful

[naasking]

Why waste your bandwidth when you don't need to? Even over my DSL line, X is somewhat sluggish. If I could get a 60:1 compression ratio(which is even modest according to their website), that would be amazing.

-----
"People who bite the hand that feeds them usually lick the boot that kicks them"

Re:bandwidth

[martyb]

i think the biggest problem with running a remote X desktop to your handheld or cell phone or whatever else would be bandwidth.. it just isn't there for little portable devices.

Not Quite. The article mentions the client uses on the order of 10 MB of memory to cache things. Not too many cell phones have the kind of storage available.

Terminal Server

[NineNine]

Microsoft already has Terminal Server for W2K that works well with low bandwidth connections. It doesn't draw the screen, pixel by pixel like VNC does. Instead, it uses the BMPs and the APIs already on your desktop to very quickly let you work on the other machine. Terminal Server works fine across a 28.8 connection. XWindows needs something to compete.

Re:Terminal Server

[TwinSpark]

1. X is free (!)
2. X is standard (!!)
3. X sucks, indeed, but it's much easier to
improve it that to impose another standard

Re:Terminal Server

[Znork]

Actually, X over 28.8 has been fine for a long time, with dxpc, compressed ssh forwarding or commercial products like Go Global. At my company we have a lot of people over 64k WAN links running X applications with Go Global.

Its just that most people dont bother, since over a low bandwidth link you're never going to get good enough performance for ordinary desktop use (the added latency for clicks and graphics that cant be compressed kill the idea with or without efficient protocols). And with unix you can always use the command line, which eliminates the actual need for it in most everyday situations.

Remotable displays are great on LANs, but they can only be made less painful over low bandwidth connections.

(Oh, btw, X uses server side (desktop) drawing and bitmaps mostly even without compression.)

Re:Terminal Server

[pete-classic]

In X VNC does very well drawing at a higher level than pixel by pixel.

It "tries" in windows, but, unfortunately, since windows is a black-box, it is not very successful.

See http://www.uk.research.att.com/vnc/faq.html#q36 and #39

Nice troll though.

-Peter


"There is no number '1.'"

Re:Terminal Server

[spitzak]

This is very commonly suggested, and I think it is completely wrong. We do not want the toolkit to reside on the server. I worked on NeWS, which was an excellent system, but I think this approach resulted in the system being unusable for outside programs.

The main problem is that toolkit widgets quickly bloat up to have a huge amount of data that describes them. I think it is very likely that the amount of data will exceed the few rectangles sent to draw the widget. This is true of the ICCCM protocols for window managers: I have written a toolkit and a window manager, and I believe the code I need in the toolkit is about 3 times larger than the code I would need if I could just draw the window borders and handle drag + resize myself. Meanwhile I estimate the window manager is 85% communication code and only a tiny portion of actual drawing and event handling.

The other, and far more serious, problem, is that you will lock the interface into current toolkit design ideas. If X had been designed like this we would be forced to use the very early Athena widgets, and they would never have been changed due to the above-mentioned interface complexity. Because X was not designed like this, despite it's problems, it is able to emulate interfaces developed 15 years later with no problem!

Re:Terminal Server

[NineNine]

Well, if what I wrote is such BS, why don't you enlighten us, oh great one?

Re:Terminal Server

[NineNine]

Look who's calling the kettle black...

Re:Terminal Server

[j-pimp]

How hard would it be to modify, lets say GTK, so that instead of X transmitting X drawing primitives it would transmit GTK primitives. I assume thare are at least 20 or so X primitives involved in a simple GTK scroolbar. The same for QT, window managers and the like. I lack the knowledge of X to code it myself, but I might be able to help out with some of the testing. If anyone else is interested email me at jJuUsStTiInNdDeEaArRiInNgG@poboxes.com. yeah remove the caps to email me.

Re:Terminal Server

[QuoteMstr]

So what you're saying is that Terminal Services is doing what X has done for fifteen years?

Re:Terminal Server

[robert-porter]

Why is he a Troll, because he mentioned Microsoft did something good?

Re:Terminal Server

[BeanThere]

No, its because his post is, technically, complete and utter BS. I haven't read a /. post so technically inaccurate in a long time. So either he is incredibly clueless, or he is a troll. Hard to tell though.

Re:I need this!

[figment]

On the topic of latency, which ppl brought up earlier, 802.11b is probably one of the scariest latent technologies. Given the vendor implementation of 802.11 (frequency hopping vs. fixed frequency, the latter is more popular because of easy of use), if it uses frequency hopping, you're looking at modem-caliber latencies, just to your firsthop (the access pt).

Having 1mbit (or 5.5, or 11, whatever you're using) of bandwidth per client isn't going to be the biggest factor in the performance of the device, the latency is going to be a very big issue.

Re:trying to compile this thing..

[figment]

ldconfig

The linker keeps a cache of the libraries it has, you need to rebuild the cache when you add libraries.

Re:VNC

[dan_bethe]

Have you guys ever heard of TridiaVNC? Tridia is a company devoted to the development of VNC. They host some good mailing lists, etc. There are ideas out there for embedding VNC inside of Basilisk II so that we can have a MacOS application server, for a sliding scale selection of various compression for various latency/bandwidth usage combinations, and Yggdrasil has added automatic VNC attachment features directly to XFree86 so that you don't have to run your apps in a VNC server first in order to connect to them later and also enjoy fully local performance. Search the mailing lists at http://tridiavnc.com and scour ftp://ftp.yggdrasil.com.

BTW I think that Win4Lin is making a remote Windows app server which might be based on VNC.

VNC is like magic, man. That's where it's at. :)

===

Re:VNC

[bencc99]

I completely agree with you on the first point, but the statement about the Windows Terminal service shows that you don't seem to have it used once. In our school we've got 100 MBit LAN and Terminal Server is still slow as a snail. I can't imagine running it over ISDN, let alone modem.

I doubt that's down to terminal services - running it on reasonably fast machines over 128k is quite usable - I've done it more than once from home when the windows guys at work aren't answering the phone. Over 100 mbit net, it's *very* fast.

Re:bandwidth? Nope, Screen Size...

[Anonymous Coward]

Bandwidth is either here or coming down the pike. But, as a HHLinux iPAQ user/developer, I can tell you the major problem of running remote (and non-remote) X apps is SCREEN SIZE. Most apps just aren't designed to run on a 240x320 screen. If they are written using a standard toolkit, new widgets can be coded that take up less space (the big margins and other wasted space look good on a large monitor, but eat up valuable real estate on a handheld). It sure would be nice if somebody got the itch to create some smaller GTK widgets, hint, hint... Take xpaint, for instance, it will work on the iPAQ, but you have to scroll around to get to the tools, colors and other controls. Usable, but a bit of a pain. Cpt_Kirks

Re:VNC

[floki]

Do you think a PIII 600 with 128 MB RAM is good enough to get it going fast over 100 MBit? That's what we have and apparently it isn't quite sufficient. Perhaps something is misconfigured. Any ideas?

Re:VNC

[bencc99]

I have no idea.

must be that randomness M$ puts in to all it's products that decides how well (if? ;P) it works....

Re:another thing to consider....

[vr]

HA! just try to mention opensource developers and "lightweight" in the same sentence. IT WON'T MAKE SENSE! that's what happens when you spend your life in an easy chair in front of a monior.

Well.. you may be right.. Nah. Please realize that Open Source does not explicitly mean that the developers are idiots. It doesn't even mean that they do it on their spare time! *gasp*

There are actually people getting paid for developing open source code! *shock*

Re:How useful

[Jeremy Erwin]

As a graduate student, I occasionally need to run xmaple, or matlab remotely-- but only have a 56k modem. (Yes, I do have local copies of the programs, but sometimes I need to test if my files are compatible with my school's versions.) Low Bandwidth X, while not a panacea, does allow me to run some of these programs.

Why remote?

[DeadInSpace]

It might just be me, but I'm perfectly happy running all my applications locally on my own machines.

With all this .NET and remote X stuff, I'm wondering, why would you want to run such things remote? It makes you extremely dependant on your internet connection, and a 0.1s (with 100ms network latency) delay between my actions and the computers reactions is kind of irritating.

Now, I've run X applications (and even entire desktops) remotely, and it's fun to try and can be very useful in some cases, but the lag was noticable, so I strongly prefer to run things local.

----

Re:Why remote?

[Cirvam]

Lets say you want to render a huge 3-d image or something that would use tons of processor power. Do you want to sit at your computer for 5 days waiting for it to finish? or just offload it to a faster computer so that you can still use yours for other stuff. Plus this would be extreamly useful if you are at collage or something and go home to vist your parents, you could still access importain stuff on your desktop.

Re:Why remote?

[jellomizer]

Remote X is a good way of accessing System pasific programs. When you dont have those systems. Example WordPerfect 2000 works on Linux and not on Solaris. When I am on a Solaris system I can do a remote Xconnection to the Linux system and Use wordperfect on a Remote Sun system (Which is is in the computer lab). Example2 Say you need to use Maple (for Math Stuff) But you dont have a copy yourself but there is a UNIX box using it elsewhere where you have access to. The Remote X saves you a trip to the computer Lab. Or you can do you work when the lab is closed. There are also some cases where a remote X is faster then the actuall box as well. We have a Very Old Sun Sparc Classic Running as a webserver. And they are some graphical Configuration tools that are a lot quicker to work with then threw the config files. When I use a remote X conection the work on the Sparc Classic has droped a lot becasue My computer is buisy making the fancy graphic while the Sparc is just sending the data. And the Remote X actually goes faster then using the system locally. System Admininsters can have a bunch of XLoads on one terminal and keep an eye on many Unix boxes and not have to run from system to system. Remote X is really a good idea. While the .Net you loose the ability to switch Platforms as well becuse M$ dosent want to do things the right way.

Re:Why remote?

[SCHecklerX]

#2's my favorite use. Rather than having to get up and use my desktop computer, I can run apps on it from my laptop computer in bed while watching TV.

Yeah. It was a great way for me to surf on the faster computer and also to check mail with the mail client on the main computer from the lower powered laptop from bed for a couple of months when I busted my ankle last year!!

Re:Why remote?

[DeadInSpace]

I understand that the ability to run things remote is very helpful in those cases (and I do that too, occasionally), but I often get the impression that the future should be that *everything* will be run remote, and I don't like that. I just run most things local, and only the things I can't or don't want to run local (for example, for the reasons you gave) will be run remote by me.

----

Re:Why remote?

[cyberdonny]

A couple more:

• Access to legacy apps which do not yet exist on your chosen desktop platform?
• App needs to run on remote computer, because it controls hardware attached to that computer. Granted, today you could use a small webserver on the computer where the hardware sits, and use HTTP for client/server communication, but what if the hardware is closed and legacy, and only ships with an closed-source X app running on SCO?

Re:Why remote?

[nebular]

it's fun to try and can be very useful in some cases

Exactly why, it can be useful. The logic here is that if it can serve a useful purpose then it should be explored and improved so that it can be even more useful.

Sometime local isn't an option. Perhaps the program takes up too much space, or perhaps it's a unique situation that requires the program be on a specific computer. The fact that cases like that exist and that more useful cases can be imagined make a good case for expanding and improving the technology.

But at the most basic the best reason to develop remote GUI is the fact that people can tell the difference between local and remote (ie it's slower). Once you can't tell the difference anymore then I'm sure you'll be using it.

Re:Why remote?

[mandolin]

and only ships with an closed-source X app running on SCO?

when linux 2.2 was still the thing, it had somewhat working SCO binary emulation if you dug around. If your binary was statically linked (they mention sco wordperfect(!) in the readme), you might be in luck. I played with it enough to verify that it worked for simple apps, but it broke when I started trying to do socket stuff (which used a streams interface, which wasn't working on linux as I recall) .. now given that I don't know how an X app *could* work, but apparantly It's Been Done.

buck

Re:Why remote?

[cyberdonny]

The situation I was thinking about is the following:

• The app runs at a central site, where it controls machinery/other installations physically located there.
• Maintainance personnel on call connect to the app from home, to check on the system. They do so via a Laptop connecting via ISDN to the central site.

Problem: the app is an X app, which is very bandwidth (and latency) hungry, and to which no source is available. Moreover, as the institution is not in the business of doing software development, rewriting it to a different protocol would be out of question even if source was available. Your suggestion (of using binary SCO emulation) looks good, except for the fact that we'd still be running X over a slow ISDN line... Only difference: the app would run on a nice shiny Linux box rather than an old SCO iron, but the bandwidth/latency problem would still stay the same... So far, the only viable solution seems to be a dxpc-like X compressor, and in this context, the mlview-dxpc is indeed godsent.

Re:Why remote?

[SCHecklerX]

A couple come to mind:

1. Administration. Much easier to control people from a single box.
2. Home networks...You can buy a cheap "x-terminal" (think old 486 laptop, or better yet an I-opener), and run the apps on your big-honkin' server. this is great for browsing usenet news from any location in the house, btw, and always having the same articles marked as read no matter where I am.

Re:Why remote?

[SCHecklerX]

A couple come to mind:

1. Administration. Much easier to control people from a single box.
2. Home networks...You can buy a cheap "x-terminal" (think old 486 laptop, or better yet an I-opener), and run the apps on your big-honkin' server. this is great for browsing usenet news from any location in the house, btw, and always having the same articles marked as read no matter where I am.
3. X forwarding is the perfect solution for places like libraries, internet cafes, bookstores, etc. Much easier to administer ONE box than a few dozen.

Re:Why remote?

[figment]

>With all this .NET and remote X stuff, I'm
>wondering, why would you want to run such things
>remote?

Cost. Rather than buying N equal workstations, with N harddrives and N of every peripheral, you can buy one rather large server, then deploy diskless workstations with a network connection, then run all the apps on the server over the network. Sun has a product line called the Sun Rays that do it (and they've been doing it for a while, we have some 5 year old diskless workstations lying around too). It makes administration easier because you have one server to care about, rather than N workstations, and because all the cpu use is on the serverside, assuming you get decently beefy workstations, you'll never need to upgrade them.

Performance wise, on a 100mbit network, the latency isn't really an issue, it is tolerable, if even noticeable.

There also is that server thing, if you're administrating lots of servers, using a dtlogin or a terminal service makes things so much easier, instead of you having to move each server to your desk, or you doing work right next to the racks.

Re:VNC

[TwinSpark]

For all *VNC-is-great guys: Have you ever tried to WORK using your *VNC based connection? I mean, not only doing simple administrative tasks, but work? Write an document in staroffice, reply to some slashdot posts in konqueror/netscape? And everything using a ISDN modem with ping of 200 ms? I have tried. It is impossible. Sorry.
It could have been possible if everything had been written using some "light" toolkit and X protocol greatly modified but unfortunately it isn't.
The goal of ML-View is to make it all possible using standard X server, standard qt/gtk toolkit!
And the problem of using it under Windoze, MacOS or anything? You use dxpc now, you will use mlview-dxpc soon. Leave us some time.
Maciek, YAMD (= yet another mlview developer)

Sun's done this already.

[dynweb]

See here. for the Sun Ray series of products. I've used them before -- they're really quite nice.

OT: WTS (was RE: VNC)

[Nothinman]

You need more memory, 128M is the minimum required by MS. Also each user logged in gets so much memory allocated for the desktop and for each app they run, allocate an additional 10M minimum for each user connecting if they're only running 1 app at a time, add more if they're running more than one app at a time. I would try to give each concurrent user ~30M, more if possible, and don't forget about how much memory the OS itself needs.
--

Re:bandwidth

[smellmypacket]

using a browser based solution like thinwireless.com, and a phone with a java browser and gprs it maybe could be done

bandwidth

[waspleg]

i think the biggest problem with running a remote X desktop to your handheld or cell phone or whatever else would be bandwidth.. it just isn't there for little portable devices..

Re:bandwidth

[boaworm]

Yes. Bandwidth is the problem. Since GUI's are becomming more "graphical", with lots of colors and other features, more bandwidth is required

Furthermore, if you would make a 'clean' GUI just for the sake of transporting it to remote boxes, you'd miss all the new multimedia features required nowdays. How funny would that GUI be without a proper browser (banners, images etc...), mediastreamers etc ?

Re:bandwidth

[waspleg]

exactly, i mean the article says it uses a 4 Kb/s stream.. that's too much for most people on dial up.. i mean what good is a desktop if you can't do anything with it because it's strangling your bandwidth.. seems pointless to have an X desktop running on a handheld remotely anyways.. why not spend their time working on a stripped down versino that runs natively

Re:bandwidth

[Alien54]

i think the biggest problem with running a remote X desktop to your handheld or cell phone or whatever else would be bandwidth.. it just isn't there for little portable devices..

Agreed. However, I found this snippet on the website. Grammar aside, it sounds like they have licked a few problems. Although it is tough to stop feature creep and other oddities from bloating the software.

People who has tried it, reported mlview-dxpc to be an order of magnitude faster then any other OSS solution they tested so far. Personally we ran it, head to head, against Citrix WinFrame. Performances are comparable.

If they get this working, could be fun.

Re:bandwidth

[SEWilco]

4Kbits/sec is certainly minor now. 1200 bps is 1.2Kbps. People consider a 14.4Kbps connection to be slow, and 4Kbps is much less.

I've used normal X through a 1200 bps modem. Text windows work just fine, it's graphic windows which gets slow.

Re:bandwidth

[Shanep]

Dude, have you ever used X or VNC Window sessions through a network? Very very fast, they were built with this in mind.

Ever seen diskless X terminals? They boot from another server, through a network and they are graphical and surprisingly quick!

We're talking about some pretty smart caching software here that copies across the network the bare minimum to get the job done.

If they've got this working well in just 4k_bits_ per second (thats about 8% of what a 56k (okay 53k) MODEM can do, then it's going to be awesome.
This actually falls well within uncompressed GSM DATA transfer rates, meaning that this can give incredible functionality to lowly PDA's, etc.

Of course, I agree that some things, like web browsing, where a lot of new (uncached) images will have to be downloaded, will be a bit of a downer. But with office productivity apps and the like, where caching can be effective, this will be great.

Imagine a PDA with the power and storage capabilities of big iron, except in your hand! Who wants to do great ammounts of browsing and multimedia stuff on a PDA anyway?

I mean hell, how fast is your browsing going to be and how huge are your multimedia experiences going to be on a PDA without this anyway, with their CPU, memory and connectivity limits?

This is basically a great way to improve much of the things that are holding these sorts of devices back anyway. So don't think of it as more silly drawbacks, think of it as great efficiency where it is needed most.

Bye for now.

Re:bandwidth

[Shanep]

some of the remote desktop stuff I do

Obviously you're not using X or VNC? You're using some security disaster like PC Anywhere?

I have worked with firms where they had many diskless X terminals on 10Mbit hubs sharing bandwidth with MS PC clients!

Worked nicely. It's not like the server end is treating the client (actually, should I say the client is treating the server? ;)) as just a frame buffer!

Re:bandwidth

[Alpha State]

That is the entire point of this project, to reduce the bandwidth which X needs. Advice to the void: please gain understanding before posting, intelligence beats speed every time.

PS: This would be cool - I run a client on my laptop for computing while in bed. Doing so over the internet would mean that every place is my home :-)

Re:bandwidth

[Trepalium]

Actually, they mentioned 4Kbps, which is kilobit, not kilobytes. If you can't pull 4Kb/sec over your dial-up, I feel bad for you (approximately 0.5KB/sec), since the average 14.4Kbps modem should be able to pull over 3 of those streams. I don't think the point of this is to preclude a local GUI, but rather make it possible for applications that are too large to run locally be available to be run remotely.

Re:bandwidth

[Alien54]

As also noted on the site:

Note that mlview-dxpc is not yet for the casual user. You won't find any GUI (what do you expect from a MS1 ;-) and you'll need some knowledge about how X is handling its DISPLAY.

so this becomes another semi-advanced thing, depending on your expertise, etc.

Re:bandwidth

[holloway]

X is pretty dumb in the way of describes graphical primitives (much unnecessary network traffic). If one were going to do a rewrite they should learn from Berlin's trim structure (although CORBA certainly bloats).

Re:bandwidth

[naasking]

But that was with a pretty heavy load though... C++ coding, e-mail and webbrowsing all at once. They also said it attained a modest 60:1 compression ratio in that case. The max is 400:1. Not to shabby IMO.

-----
"People who bite the hand that feeds them usually lick the boot that kicks them"

VNC with TIGHT ENCODING is what you need.

[Anonymous Coward]

If you use vnc with the tight encoding patch you get a GREAT speed up. It was written with dialup speeds in mind.

What else do I use VNC for? I start a session on my dual PII linux box in the basement and use it to run eroaster/xcdroast and limewire (great gnutella client). Long running apps that you would like to connect to and leave burning/downloading for days are a perfect reason to start a vnc Xserver (Xvnc).
Remember folks, the unix vncserver is not a screen scraping type app like the windows one, it's basically just a standard X server WITHOUT any hardware support. There *IS* a way to get the screen scaping type functionality under unix though, using x0rfbserver.
http://www.hexonet.de/software/x0rfbserver/

http://www.google.com/search?q=vnc+tight+encodin g
http://www.google.com/search?q=limewire

-kcurrie, too lazy to login..

Re:VNC

[wik]

The problem is that the App needs to be written specifically to talk RFB (the Remote Frame Buffer protocol that VNC uses). It's not simple, and to re-write a Windows App like that is very difficult.

There were murmors on the VNC list (before the S/N ratio dropped like a rock) of someone who actually write a Java wrapper for AWT (and Swing, I think) that lets all Java apps easily act like RFB servers with a few code changes. I never tried it, though.

Re:Grunge dropping New Jack through a press table

[Graymalkin]

The main difference in this example is whether or not the data is going to be drawn or not. Using CORBA or COM+ I can give remote users access to my server's libraries as if they were on the remote machine whether they have to do with GUI stuff or not. It's a matter of dealing with actual objects or dealing with a widget set. For alot of distributed applications I think I'd go with object handling and let my client program decide how it wants to draw the information.

VNC

[perlyking]

X is good, low bandwidth would be better (and judging by what the site says it is better) but I can't help thinking VNC is actually more useful because its only a couple hundred k of program and runs on platforms as diverse as Linux, beos and windows CE (amongst others). Of course YMMV

Re:VNC

[cowmix]

This totally is not true. I use VNC over a 28.8 line all the time and the performance is very good. The thing that is great about VNC is that it adapts to how much bandwidth you have.

Re:VNC

[bacchusrx]

Despite the wonders of the Tight Encoder I have still never been WOW'd by VNC's performance. I have a broadband connection to my LAN at home (3 roommates, 5 computers, 2 cable connections capped to 50KB/s upstream on each connection) and I use VNC to get access to my X desktop from work. One of my co-workers has the same setup but with Win2K Advanced Server w/Terminal Services (and a Win2K session, obviously ;)).

Frankly, WTS leaves VNC chokin' on the dust ;) I'm always surprised when these threads inevitably show up on Slashdot and large groups of people praise VNC for its sweet goodness when I've never really seen that sort of performance. I have hope for future versions of TightVNC, though... so we shall see...

Has anyone had any luck with the new JPEG compression?

BRx.

Re:VNC

[Ed Avis]

Bandwidth isn't the problem, it's *latency*.

Try running XEmacs over a 28.8Kb/s modem link. You'll see the 'send' light flash, then the 'receive' light, then 'send' again, and so on for several minutes. This indicates to me that a lengthy dialogue is happening between the X server on my machine and XEmacs running remotely; and that each side can only say one thing, then wait for an answer.

Most likely XEmacs is asking about all the fonts available and their sizes, or something like that. Maybe it is querying X properties one by one. But anyway, it would be a lot quicker if the X server could just send a single, highly compressed lump of information containing almost everything XEmacs (or any other X client) needs to know. Alternatively, make the communication more asynchronous so that X clients can send several requests at once, without waiting for an answer between each one. Going backwards and forwards across a modem link usually takes about a quarter of a second (for me) - do you want that sort of delay for each of a hundred messages?

VNC (even with compression) is a bandwidth hog compared to X, but it's not so much of a 'latency hog'. Running XEmacs over VNC, it starts much quicker, because the X server (Xvnc) and X client (XEmacs) are on the same machine. The communication that goes over the high-latency modem link does not consist of lots of small requests, (it's just raw pixel data) so the application's response time is a lot better. (At least when starting; if you wait several minutes for XEmacs to start with X-over-modem, it's just about usable once it's running.)

The irony is that compression, which is supposed to make the link effectively faster, actually increases the latency for sending short messages. Of course special compression designed for the X protocol will be designed to minimize the effect on latency.

Re:VNC

[cyberdonny]

> The irony is that compression, which is supposed to make the link effectively faster, actually increases the latency for sending short messages.

That would be true if you used a protocol-independant compressor such as ssh. However, the X-compressors (mlview-dxpc, lbx and to a lesser extent, classical dxpc) all know about this issue, and compress "intelligently": they try to cache session states, and satisfy some requests locally from the proxy, thus cutting out round trips. The problem so far has been that dxpc was not very efficient at this, but according to their blurb, mlview-dxpc is much more sophisticated in this regard.

Re:VNC

[dan_bethe]

Yes I have. For about the last 6 months, I've done absolutely _all_ work, _all_ day, exclusively via stock VNC from ORL, over a 10mbps LAN. Full usage of all applications: full multimedia web browsing, text editing, system administration, xchat irc client, all that. From MacOS or IRIX clients, to a Linux server. I understand what you _mean_ about the performance drop, but I simply haven't ever seen it beyond that of a fraction of a second, and only occasionally during certain types of tasks. So I'll keep an eye out, but I can't imagine how it could be a problem unless you're excruciatingly impatient or intolerant. :)

There are people who call fast things "slow" only because they're less fast than something else. And who will say that downloading a 600MB file over a modem is "impossible" just because it takes more time. I'm not saying that you're one of them, and I'll keep an open mind and read all the opinions and research, but I don't personally see a problem.

===

Re:VNC

[modecx]

I will have to agree on the latency issue. Using a terminal remotely over a 1200bps modem (direct connection to the server) is alot easier to put up with than having a T1, and using a terminal somewhere in Taiwan (with a latency of 3 seconds - [if the packets aren't dropped multiple times by then that is]). For me, operating a remote terminal is only bearable with a latency under 250ms, and then preferable to be under 100ms. That's just my opionion, though.

Re:VNC

[mini me]

The problem I see with VNC (and Terminal Services for that matter) is that they send the whole desktop over instead of the running app like X does.

I already have all my desktop setup running on the computer I'm using so why do I need another? X intergrates the application into the existing environment and almost makes it transparent to the fact that it isn't running on your computer.

The only advantage that I see to using the VNC, Terminal Services, etc. way is that if you have a device that is made just for that say a VNC device that doesn't have any sort of desktop and it just uses the remote one. But if you already are using a full fledge desktop on your computer, running another on a remote computer seems redundant.

One problem I see with the X protocol though is that clients behind a firewall can't run X apps on a remote server (without setup on the firewall anyway). I have never used X tunneling via ssh so maybe it solves this problem?

Re:VNC

[Scotter]

Go to http://www.tightvnc.com. They're doing some clever things to make bandwidth MUCH less of an issue. (Including lossy jpeg sessions if desired.)

Re:VNC

[__aasmho4525]

i agree.

we use w2k advanced + metaframe at work quite freqently.

even over a ds-1 over 1200 miles long, its totally completely useable.

better than having windows on my desktop, really :)

Peter

Re:VNC

[mpe]

I can't help thinking VNC is actually more useful because its only a couple hundred k of program and runs on platforms as diverse as Linux, beos and windows CE (amongst others).

Except that there are plenty of things VNC can't do. e.g. the equivalent of an arbitary number of "xterm -display :0"

Re:VNC

[DrSkwid]

have you ACTUALLY used it or are you just guessing?

It uses it's X server so you configure it for your VNC clients to the spec you want.

But it is a pain over dialup but if you type ahead it's not such a problem.


.oO0Oo.

Re:VNC

[BeanThere]

I find VNC very quick on 10Mb lan, even some interactive games like xboing are very playable, and not even a quarter of the 10Mb bandwidth used. It was fairly usable even using my 28.8 modem at home. Much quicker than PCAnywhere. I did some tests though and found it wasn't very quick when the server was running on platforms other than Linux (e.g. Windows.) Connecting to a Windows session was much closer to PCAnywhere slowness. I do run icewm though, which is much lighter than gnome or kde. I've never used terminal services, so I can't really compare it - but in general, Windows was just not designed to stuff like this at all, and X is; so Windows is almost inherently going to be slower.

Re:VNC

[nowt]

Giving credit where it's due... Citrix is where "Terminal Server" came from. For the ability to have all source code to NT, Citrix had to 'give back' what it developed to MS in the form of Terminal Server.

But it took an entire rewrite of the o/s to create an environment conducive to low bandwidth remote sessions.
I use daily for access to Outlook/Word/Excel apps on citrix server while mainting my linux laptop for normal comforts.
-Nowt

Re:VNC

[BeanThere]

But if you already are using a full fledge desktop on your computer, running another on a remote computer seems redundant

Not entirely. VNC lets you run multiple desktops from the same machine. In fact in my case, I have a linux box set up with no local display at all (no monitor) which is actually running VNC desktops for three users. They're not very heavily used, so they perform well. They're also running from a slow old Pentium with only 64 MB ram and a 10 Mb lan card, so all in all they run pretty well.

Re:VNC

[bencc99]

the problem with VNC is that it requires *huge* amounts of bandwidth - it's sluggish over 10 meg lan, and certainly isn't manageable over dialup. X does work nicely over some other platforms - eXceed under windows being a good example.

I think the real issue is that X isn't well designed for low bandwidth use - try something like MS (ick, I know) terminal services, and it's quite useable over 128k isdn, or even over 56k if neccesary. It can be done - it just needs a more efficient use of bandwidth than X currently does.

Re:VNC

[floki]

I think the real issue is that X isn't well designed for low bandwidth use - try something like MS (ick, I know) terminal services, and it's quite useable over 128k isdn, or even over 56k if neccesary. It can be done - it just needs a more efficient use of bandwidth than X currently does.

I completely agree with you on the first point, but the statement about the Windows Terminal service shows that you don't seem to have it used once. In our school we've got 100 MBit LAN and Terminal Server is still slow as a snail. I can't imagine running it over ISDN, let alone modem.

floki

Re:VNC

[The Original Bobski]

The only sluggishness I ever experience with VNC is when one or both computers are running Windows.

Using VNC in an X to X configuration is extremely fast, even on a 10M lan.

I was quite surprised the first time I saw a fast moving screensaver on the remote bax being updated locally in near realtime.

Re:trying to compile this thing..

[ikekrull]

This works great.. i feel dumb now :)

Thanks

Re:X protocol chattiness is the problem not bandwi

[Paul Jakma]

Well, we actually use Citrix+MS Terminal Server in work too. And by god does that absolutely suck.

The biggest problem is the Terminal Server side of things, it requires heaps of RAM cause multi-user is obviously just a gross hack - each user is just assigned a big block of memory, and if they all run excel, each users address space has to have the text loaded in. We have an NT box with half a GB of RAM just so that about 20 people can run word/excel/proprietary windows app.

no sharing of text between different users. ugg..

the citrix display exporting side of things works quite well (though it can very occassionally hang the display). but then, X works /really/ well - its a lot faster than citrix/TS on a LAN.

I notice you didn't bother to even try justify your claim of "[X] is an old tired technology". what specifically needs improving? Anti-aliasing extension has been written and implemented for XF4, this very article is about a new X compressor. So what do you mean with "never improved"?

from the non-technical POV, citrix+MS TS is an absolute nightmare in terms of licensing. you pay for MS the local NT workstation client, for TS and per-user licence for TS. Plus citrix per user on top of that...

uggg..

--paulj

PS: nice troll, but not good enough.

Why do you read Slashdot ?

[Choron]

You should be happy with your local Slashdot server, why view such a thing remotely ?

every place is my home :-)

[Tony-A]

That, my friend, is the future of the internet. It's really more of a "thin-wire" thingee than a "thin-client" thingee.
(Begin rant. Even the small dumb PDA-type thingees need to be "multi-user". Multi-role might be more descriptive. "My Computer" seems somehow incredibly stupid. End rant.)

I need this!

[LinuxHam]

I'm about to pilot test 10 Linux-based webpads running 802.11b in April, another 500 or so in September, with the hopes of blowing it wide open to a few thousand next summer. The deployments will typically have 3 access points per 30 units. Seamless roaming will not be supported.

I want to propose a monster box to run the apps, and many smaller boxes managing the displays of the 30 or so portable units per group. With each unit getting up to 1Mbit/s of bandwidth, then low-bandwidth X on an otherwise embeedded-class handheld sounds like it will be an excellent solution to my problem.

Steve
--

Re:I need this!

[vineland repatriate]

Steve wrote:
"I want to propose a monster box to run the apps, and many smaller boxes managing the displays of the 30 or so portable units per group. With each unit getting up to 1Mbit/s of bandwidth, then
low-bandwidth X on an otherwise embeedded-class handheld sounds like it will be an excellent solution to my problem."

Consider showing whoever you're pitching this at the following:

http://technetcast.ddj.com/tnc_play_stream.html? st ream_id=233

Since it sounds like you're planning to deploy this within a cubicular environment, I think you can adapt the spring-loaded "jumping" element to fold out the displays on your webpads, sacrificing your rovers' ability to hop over obstacles. The alternative, however, would be to find a way to run the X interface in scrolling mode along the surface of the rovers, so that what your users were interacting with was always displayed on the visible surface.

I suspect you may have a bit of trouble with your building's security folk if they happen to see you coming in with the grenade launcher for remote deployment, though, so you may want to bring it in disassembled for the live demo.

If your proposal looks to be going south, having the grenade launcher with you gives you, ahem, another modality for response to criticisms provided you bring along a few samples of what can normally be deployed with a 40 mm launcher.

The opportunity to provide clear and concise feedback to the reviewers' smallminded thinking, to paraphrase from an old .sigfile.

-Peter

Still no support for resumable desktops

[ideut]

When I first saw this article, my first thought was that The Thing I Had Been Waiting For had arrived. I thought that we were going to get resumable X sessions.

Resumable X sessions would absolutely rock. There is always a lot of setting up to do when one starts an X session - I don't care how much effort you put into .xinitrc or how intelligent your desktop environment's session management is - there's always lengthy initialisation for my X sessions. Resumable X sessions, combined with a low bandwidth X proxy, would allow me to:

1. Use my same desktop from anywhere in the house (at the moment that's three machines with decent displays)
2. Access my home's desktop from the computer laboratory in town during the day time.
3. Display applications running on various shell accounts across the internet at home and not have to start over when my DHCP IP address changes.

   At the moment I can (and do) use VNC for (1) because I have a fast home LAN. But even tight VNC is too much of a bandwidth hog for (2) or (3).

   Hell, if resumable X displays existed I would probably rent a colocated box on the net's backbone, then just use thin clients (read: sleek X servers) to access my desktop from wherever I happened to be in the world.

   Does anyone have any thoughts on the architecture of the X 'proxy' that needs to be invented? It would have to be a full-fledged X server, and would have to maintain state for any clients which were displayed on it. It would also have to be an X client, capable of displaying itself on a remote computer, but capable of "detaching" from the display and "re-attaching" to another one (that's why it needs to maintain all the state of any clients which are displaying on it.. )

   Colour depths would be a nightmare, as they always are with X.

   Perhaps extending VNC so that "X protocol" is one of the encoding options for communication between VNC server and VNC viewer would be a place to start (though I'm completely ignorant of how easy it would be to graft stuff like this on to VNC).

   I'd be interested to hear what others have to think on the matter.

Re:Still no support for resumable desktops

[Nailer]

1 .Use my same desktop from anywhere in the house
2. Access my home's desktop from the computer laboratory in town

x0rfbserver. A Unix/Linux VNC server that acts like a Windows one, where the remote user takes over the desktop.

Re:Still no support for resumable desktops

[garrettl]

It already exists, and has existed for a number of years now... (since 1995)

It is called "xmove", and is available from ftp://ftp.cs.columbia.edu/pub/xmove/

If you're running Debian, then it's only an apt-get away.

If running Red Hat or any other RPM-based distribution, there is an i386 and src RPM available on the 'Net as well.

In addition, I suggest that you try out x2x. Think "Xinerama" across multiple desktops over the network. It's kind of like that. With the combination of x2x and xmove, you can actually move the displays of X applications across machines, and control all of the boxes from one control point. Good stuff. (:

Re:Still no support for resumable desktops

[ideut]

Thanks for the info, but it is remote frame buffer based. I want something which talks X all the way.

Re:Still no support for resumable desktops

[ideut]

Dear garrettl,

I love you. I just apt-got it and had a play. It seems pretty functional.

Thanks a *lot* for the info. You wouldn't believe how much time I've spent looking for xmove.

However, it's still not everything I want. I want to be able to hit Ctrl-Alt-Backspace on the X server and have the X client survive (the equivalent is possible with vnc). Or I want my modem to disconnect and for me to be able to dial up again and resume the session. But this is definitely a very good start and will be immediately useful.

Bandwidth not the only problem

[Jakdaw]

The ability to work on lower bandwidth links is not the only thing that needs to be addressed with X to make it feasible for the sorts of applications mentioned above. What we also need is some way of disconnecting and later reconnecting to a previous session. Just like screen does for terminal sessions.
I don't imagine that this would be *that* a feature to add to X, with a caveats - like the screen size, bitrate etc not changing. Since low bandwidth links also tend to be less reliable (going out of range with mobile phones etc) this would be really useful and is a good reason why people often use VNC between linux systems even though they could be using X.

Re:Bandwidth not the only problem

[ideut]

Gosh. What a coincidence (see my comment just three minutes before yours). I'm glad others also think this is important. Do you know of anyone who is trying to make this feature a reality, no matter how preliminary their project?

Browsing on a 56K connection?

[yerricde]

I think a 56 Kilobit connection could easily handle 4 Kilobits.

Not when a site is slashdotted within five minutes and it isn't even sending at 4 kilobits.

(That didn't turn out too well... let's try that again.)

__________________________________________________

I think a 56 Kilobit connection could easily handle 4 Kilobits.

Wow! It'd let me surf an order of magnitude faster. From the article:

An average session, browsing the Internet, handling e-mails and coding in C++ results in a fairly satisfactory 60:1, with bitrates in the order of 4Kbps.

If "Internet" is taken to include "World Wide Web," then Slashdot loading 1000% faster is a Good Thing.
All your hallucinogen are belong to us.

Sun's SUN Rays

[Avenger]

Does anyone know what the SunRays are using? I have seen these machines run Video remotely ... what ever protocol they are using for this seems best. Not only does it have persistance across multiple machines (done very smoothly with a "smart card") but the video performance was quite impressive... any ideas?

Re:Sun's SUN Rays

[RelliK]

Uhhm, the Sun rays are X terminals. There is really nothing new to them except this smart card, which in and of itself is a dubious innovation.
___

linuxvalley.com in itallian?!? Morons..

[hemanman]

How fuck'ed up is it on a scale from 1 to 2 to have a .com website in itallian?!?

-H

Re:linuxvalley.com in itallian?!? Morons..

[EnglishTim]

.com, .net, and .org are all international domains.

The US has a .us domain, it's just that few use it.

Re:linuxvalley.com in itallian?!? Morons..

[erayzer]

Less fscked up than your grammar and spelling.

TCP/IP

[Dungeon Dweller]

If X used a different protocol, for strictly point to point communication, and a few other cute restrictions, and suddenly bandwidth is not a problem. 56K is actually blazing. It's just that the TCP/IP protocol suite is actually slow and unreliable, REALLY, in the LITERAL sense, they are called slow and unreliable protocols. You are NOT guaranteed receipt (no hard connection) and you are NOT sending data quick (round trip time plus the MASSIVE losses you take in the header).

Im late to the party

[rosewood]

Today after 3 years of half starts I finally got a dedicated box just for linux. I have a samsung syncmaster with dual inputs so I didn't even worry about a monitor switch. However, my secondardy mouse bites and I lost the ps2 adapter for my old keyboard. Well, I had been using VNC for a while now in windows and loved it. However, I am blown away with VNC, Sawfish, and Ximian gnome all done remotely - in my word - PIMP

Re:VNC: Try tight encoding

[egghat]

Check it out here! Much better than ssh+compression or anything else I tried with VNC.
Bye egghat

Re:How useful

[Knobby]

The only thing I can think of that might cause problems when moving between your local machine and the school's machine are the paths set-up to access data.. To verify the rest, just take a look at the toolboxes included in the two copies.. (I'm not sure what the cmd is, but I'm sure there is one..)

Are there Free X-Servers for Windows.

[jellomizer]

I have been searching the Net for Months to try to find an Xserver for Windows that is Free. The Closest I found was a Port of XFree86 for DOS. But that wont cut it. I would think in they days of Free Unixs with Xwindows that there would be an X-Server for Windows that is Free. I think if there were Free X-Servers for Windows it would greatly help the Unixs (And Linux too) because then there would be a comon protocall and people can Access there Unix/Linux Systems from any computer and Use their GUI.

Re:Are there Free X-Servers for Windows.

[garrettl]

Check out WeirdX. It's hosted on SourceForge and also has a project page on Freshmeat.

WeirdX is a GPL'd Java-based X server and even has ESD support. It should run great any operating system which has decent Java support (including Windows and MacOS).

Hopefully this is what you're looking for. If you're willing to try an X server for DOS, then I suppose Java is even more than adaquate. (:

Re:Are there Free X-Servers for Windows.

[BitwizeGHC]

Xfree 4.0.2 has Win32 as a possible target. It uses DirectX to do the final rendering. Can't find any binaries, though... anybody care to build some?

Re:Are there Free X-Servers for Windows.

[stsamuel]

There are several options for free X-servers on Windows. The easiest is WeirdX, a free Java X-Server. I've tried it, the performance is acceptable. You can also use Cygwin (free distribution of the GNU-toolchain that runs under Windows), then compile and run XFree86. Or just use VNC. shawn

Re:Are there Free X-Servers for Windows.

[starling]

MicroImages MI/X used to be free, but they're charging $25 for the latest version. A hunt around the web should turn up the earlier version on a few ftp sites. For example, I found it here.

What does .NET have to do with this?!

[macpeep]

Just what exactly does .NET have to do with X, VNC, Citrix ICA, Windows Terminal Server etc.!? .NET is not about remotely running Windows applications. Geez. Is it a must to involve Microsoft in EVERY single story even if they are in no way related to it?

Re:What does .NET have to do with this?!

[pinzari]

.NET is not about remotely running Windows applications.

.NET IS ACTUALLY about remotely running Windows applications. /Gian Filippo.

Re:What does .NET have to do with this?!

[macpeep]

This is getting boring but.. No.. .NET is about a common language runtime and about languge independent applications running on any platform that has the common language runtime - just like Java, except with a twist and with much more Windows-lock in. ASP.NET is about using this platform for CGI-type of dynamic web applications. .NET is also a lot about web based applications and about using a web browser as the "platform" for this (DHTML, scripts, components etc.) SOAP is about calling software on other machines over HTTP using an XML based protocol. This is all part of .NET. .NET is NOT however, about moving the display of one Windows application to another machine, like VNC or X is. So you're wrong when you say that ".NET IS ACTUALLY about remotely running Windows applications."

Re:queing is implemented in X but...

[spitzak]

Excellent analysis, this is exactly what is wrong. It is even the problem with local X servers. Unfortunately too many people think the problem is that it is a server, or that a serial pipe is used, or other things that are actually good.

The problem is the bad aspects of XLib, where huge amounts of work cannot be done without doing synchronouse reqests for information.

I think the X protocol was designed for asynchronous message flow, aspects of how damage events and window mapping are handled show that they planned this. All the synchronous messages are from the bad stuff that was added in X11, when they started quickly bloating it to provide the features (like color) people were insisting on, and were unable to do things correctly.

I see no way to get true low bandwidth unless the Xlib protocol (and thus all programs that use Xlib) is scrapped and replaced.

Re:xmove and visuals

[spitzak]

Yet another reason why the horrid Xlib interface has got to go (and why the proposed XRender interface is also no good).

We cannot have information about how the display renders in user-visible structures that are required as arguments to graphics calls. It prevents exactly the type of behavior wanted.

This means any concept of "graphics context" must be provided by static state and not by arguments to the calls. These internal structures can have device-specific information in them because they are hidden and no user code depends on their contents not changing (though I would prefer to push it all to the server).

Re:NeWS and DPS

[spitzak]

NeWS was a great deal more efficient with bandwidth than X.

One reason is the widgets resided on the server. However I have said a few times here, and still feel, that this is a very very bad idea and should be avoided at all costs.

Ignoring that, NeWS was still faster and used less bandwidth, and here is why I think it did:

The stream was a simple encoding, not a library, and not structured. Basically it was PostScript, but all the bytes with the high bit set were equivalents of common PostScript tokens, small numbers like 0 and 1, and they introduced packed arrays of float, int, or char.

The commands to create and map windows, to pick windows to draw into, and all the graphics, were entirely asynchronous. In fact synchronous communication was completely left out of NeWS design. Therefore no blocking or sync indicators had to be put into the stream.

The graphics were quite high-level. In particular compared to X it was easy to select a font and draw in it at any size and transformation. You could also draw an image with arbitrary transformation, so a small image could be blown up and this could take much less bandwidth.

You could download small graphics primitives as PostScript procedures, to make the graphics even "higher level"

DPS is not a good solution because it does not replace the window mapping and color management code of X. This is a significant part of the bandwidth.

Re:another cool use.......

[brad3378]

read the article again.

This is not a TV
It's a monitor with Television hardware.
There's a huge difference!

NeWS and DPS

[UberLame]

You know, Sun's old NeWS system was made just to solve this problem (OK, maybe it wasn't made to solve the problem, but it solves it anyway). I'm trying to get old Sun 3/160 working to try it out.

My understanding is that Display Postscript also is more bandwidth efficient than plain X. There is a DPS module for XFree, and Solaris and Irix both come with DPS modules. I'll have to test that to find out if it's really true.

TightVNC

[tessellation]

anyone interested in using remote desktops over IP networks ought to take a look at TightVNC, which implements lossy JPEG compression (finally). It's about 70% better than VNC and about 90% better than PCAnywhere 9 from my personal trials. To give you some idea of the improvement, you can now use TightVNC over ISDN from Japan with good responsiveness, compared to waiting two minutes for a screen refresh with plain VNC.

Re:TightVNC

[DrSkwid]

I don't know about low bandwidth but over my 100Mbps LAN Hextile is the best
.oO0Oo.

Re:You couldn't

[Enigma2175]

That's 4Kb/s, KiloBITS, not KiloBYTES. I think a 56 Kilobit connection could easily handle 4 Kilobits.


Enigma

Re:X protocol chattiness is the problem not bandwi

[Paul Jakma]

congratulations! an informative post in a slashdot article about X - wow! (where are all the "X sucks" posts today?)

The problem with X over non-LAN links is indeed latency - not bandwidth. X is not a fat protocol, it's very thin actually[1], but it is extremely chatty. You could have the fattest pipe on the planet to your X client but it would still suck if the latency was bad. (eg high-throughput, high-latency satelite links).

Small applications tend to be fine. eg xterm is fine over a 33.6k modem, but the bigger the application gets, the more windows and child windows it has, the more chatting the Xserver and client have to do. Plus some apps just have to do needless fancy stuff (eg as someone posted, the gimp has an animated border for selects) which kill performance on high-latency links.

X: it doesn't suck, despite what the kiddies on slashdot might say.

[1]. data that it transfers, eg icons, is larger than it needs to be as they are raw {pixmaps,bitmaps} but server caches these.

queing is implemented in X but...

[a_hofmann]

Actually newer generations of X servers queue protocol messages to a batch of many requests/replies to address this problem. The problem is, in real world applications this doesn't work out very well because of the way Xlib programs are written.

The low level implementation of X programs requires a linear flow of

REQUEST info A, SET property B, REQUEST info C, REQUEST info D, SET property E

, and so on...

Because there is no way for client nor server to understand which information/property depends on any preceding, the protocol messages have to be processed one after the other.

In cases like requests to set/request a large set of similar properties (e.g. color information), queuing takes place and messages are sent containing a whole batch of single events, but this doesn't happen often in real world applications, thus not noticably increasing performance.

The X protocol was not designed for an asynchronous message flow.

Re:queing is implemented in X but...

[hopeless case]

Well, one way to lower the back and forth would be to have a program that looked like an XServer to X applications that you ran on the remote PC, which, instead of displaying to a video card, displayed to a frame buffer in memory. Locally, you run a viewer program that connects to the special remote XServer and sends the contents of the frame buffer every so often.

If only the differences between frames are sent, as in video compression, and you have a really good compression algorithm to handle this, and you choose which frames to update wisely, then your performance for remote apps would be much higher in some important cases.

Say I want to run gnuplot on a data file with 10,000 data points in it. That can be a lot of back and forth between gnuplot and X. When the dust settles, however, and the plot is completed, it might not be a lot of compressed pixel info.

My impression, from having used VNC in exactly this scenarion over a 128kbps DSL line, is that this is exactly what VNC is doing with their 'hextile' compression scheme.

They have some way of determining when the screen is changing rapidly (not hard to imagine) and they don't send update info between the server and the viewer as often during such periods.

I haven't read their white-paper or technical docs to really know, but I can't imagine how else they could have brought up a complex gnuplot remotely as fast as I observed it unless it worked they way I just described. It was really amazing.

Re:queing is implemented in X but...

[hopeless case]

Hah! I just looked at their docs (http://www.uk.research.att.com/vnc/howitworks.htm l) and that is exactly how it works.

I quote:

The VNC protocol is a simple protocol for remote access to graphical user interfaces. It is based on theconcept of a remote framebuffer or RFB. In the past we have tended to refer to the VNC protocol as the RFB protocol, so you may have seen this term in other publications. The protocol simply allows a server to update the framebuffer displayed on a viewer. Because it works at the framebuffer level it is potentially applicable to all operating systems, windowing systems and applications. This includes X/Unix, Windows 3.1/95/NT and Macintosh, but might also include PDAs, and indeed any device with some form of communications link. The protocol will operate over any reliable transport such as TCP/IP.

This is truly a "thin-client" protocol: it has been designed to make very few requirements of the viewer. In this way, clients can run on the widest range of hardware, and the task of implementing a client is made as simple as possible.

also:

The display side of the protocol is based around a single graphics primitive: "put a rectangle of pixel data at a given x,y position". This might seem an inefficient way of drawing arbitrary user interface components. But because we have a variety of different encoding schemes for the pixel data, we can select the appropriate scheme for each rectangle we send, and make the most of network bandwidth, client drawing speed and server processing speed.

finally:

A sequence of these rectangles makes a framebuffer update (or simply update). An update represents a change from one valid framebuffer state to another, so in some ways is similar to a frame of video, but itis usually only a small area of the framebuffer that will be affected by a given update. Each rectangle may be encoded using a different scheme. The server can therefore choose the best encoding for the particular screen content being transmitted and the network bandwidth available. The update protocol is demand-driven by the client. That is, an update is only sent by the server in response to an explicit request from the client. This gives the protocol an adaptive quality. The slower the client and the network are, the lower the rate of updates becomes. Each update incorporates all the changes to the 'screen' since the last client request. With a slow client and/or network, transient states of the framebuffer are ignored, resulting in reduced network traffic and less drawing for the client. This also improves the apparent response speed.

Bandwidth already an issue

[fm6]

Consider the popularity of pseudo-thin client technology, such as Citrix and Sun Ray. These approaches take bloated GUIs and make them run on dumb clients by throwing lots of bandwidth and server power at the problem.

This approach does help with admin costs, and is handy for places where maintaining a "real" workstation is out of the question, like a factory floor. But I'd hate to run any serious apps on such a system. Except for limited demo apps, your server and network never provide real responsiveness, and the immediate feedback that makes a GUI app work goes out the window (no pun intended).

But suppose you can de-bloat your GUI? Impossible if you're running Windows or CDE, but Linux-style desktops are more flexible. (I say "Linux style" because they run fine under any Posix OS.) Consider, for example, the plugable widget themes in KDE. So far themes have mostly been used to implement graphic overkill -- but they can just as easily go the other way.

As for GIMP: do you really want to do graphic editing on a 3-inch screen?

__________________

DEFINITELY try TIGHT encoding!

[Spirilis]

I can't urge it enough. My boss wanted to study some of his Oracle stuff, but the files and db were on one of the computer lab machines... so he asked me to set up WinVNC on it and give him the IP/display#/password. I suggested to him TridiaVNC (www.tridiavnc.com) since the latest release supports Tight encoding, so I gave him the Tridia vncviewer.exe binary and set it up on the Oracle machine. He said it was so good compared to hextile encoding that it felt almost as good as running it locally. He was on a modem, while the college is on a T1. I tried it myself from home and I must say, I was impressed. Sure, the Start menu doesn't pop up instantaneously, but it doesn't take more than 2 seconds to pop up. Considering how I'm used to running telnet over my modem line, I could tolerate it well enough. I also tried a Tight VNC session to my home computer; I was able to play Xtris well enough without trouble, minus maybe tuning the speed down a notch or two to make it more comfortable. The school-to-home session was 8-bit 640x480, the home-to-Oracle-machine session was 800x600x32bpp

is it possible...

[josepha48]

Everyone always wonders is this possible. Then they do tis or do that and they find out it is. Just like cloning. But the real questions should be:

Is there a reason to do this?

Is there a market for this, or are there people who need this service (other than yourself)?

What are the moral implications?

Of course the last question does not apply to this, but the first two do. Mainly the second question. If you were to set this up would there be a market for this service and would it be a money maker. This is the real question. I think that there is company that lets you access a linux desktop from a web browser. This is not much different. You must of course pay for the service. Oh and by the way, much of the internet is going to be pay for services in the not so near future. It sucks, but all these companies need to make money someway.

I don't want a lot, I just want it all!
Flame away, I have a hose!

Re:is it possible...

[Webmonger]

Question 1 is intuitively obvious. If there is no reason to do it, no one will do it.

Question 2 is very comercially oriented. What would have happend if Linus Torvalds or Richard Stallman or Eric Allman or the founders of Apache had asked that question? And if you look at those projects, they were often started solely because the author, him/herself desired it, and for no other reason.

Perhaps it would be better rephased as "will it be useful to people?" But it's a factor in a decision, not the whole of it.

Question 3 is always a valid question, but bear in mind that morality varies from country to country, from region to region, from person to person.

Re:another thing to consider....

[j-pimp]

I've ran GIMP over 56k With an X-win32 server and clients running on XFree86-3.3.6. No special compression. Two problems:

1. Its slow, not completly unuseable, but I wouldn't want to do it on a regular basis.
2. Since the border around the select area is animated selecting an area is impractical.
   1. So its ok if you just have to use one of the scripts to make a quick logo, but its a last resort solution. Hopefully, this will improve the situation.

VNC can run pretty fast

[janpod66]

I have had better luck with TightVNC; it compresses a bit better, but I think the main advantage is that it requires less computation per tile. I use it regularly over 256kbaud Internet connections with no problems, but it seems more responsive even for local and LAN VNC connections.

xmove and visuals

[janpod66]

Unfortunately, xmove can't adapt different visuals to one another: if the X server you are moving to has an incompatible visual from the X server you are moving from, it doesn't work. VNC, on the other hand, works between almost all kinds of visuals.

So, it's a tradeoff which one to use. VNC or TightVNC probably requires a bit more bandwidth than mlview-DXPC and xmove. On the other hand, unlike the X solution, the VNC client is tiny, easy to install, and almost always works.

Re:xmove and visuals

[janpod66]

If you want a program like xmove to present a hardware-independent visual to its clients, it could easily do whatever remapping you would consider sensible. Doing that kind of adaptation of visuals is no harder in xmove than it would be if it were built into X11.

We cannot have information about how the display renders in user-visible structures that are required as arguments to graphics calls. It prevents exactly the type of behavior wanted.

We don't when we program in high-level interfaces like Gtk+, Qt, or FLTK (which you wrote yourself, so you know it's possible).

But no matter what abstraction you present to application code, you don't want to ship 32bpp bitmaps over the network to a 1bpp or 2bpp display. That's why at the X protocol level, those distinctions are made; Xlib merely exposes them. Furthermore, some applications really need to know about the differences between visuals, so an API that presents a convenient true color abstraction of all displays just isn't acceptable.

What about Local Windowing? D11, Anyone?

[ijx]

While this is ever-so-slightly off-topic, it's still extremely interesting.

Check out D11. It's a spec that calls for a major restructuring of X-Windows, but it works thusly: Speeds up local accesses to an X-Win server (running the X server and client on the same machine). The thought's been around a while, but this is some really good stuff.

lightweight clients: RDP, ICA, and VNC.

[janpod66]

Keep in minnd that the RDP and ICA clients are pretty lighweight compared to a full X installation (there are even Java applet versions). And I believe they actually take an approach to remote displays that is closer to VNC than X; I believe they (often?) transfer images, not drawing commands.

I suspect that one can probably get close to RDP or ICA performance with careful tuning of the VNC protocol. TightVNC is an attempt to do that.

What would VNC need to become even faster? I think VNC right now has no provisions for drawing commands at all. Extending the protocol to add a few drawing commands might help; servers could generate them if they have the information to do it. For example, a simple BitBlt operation would make scrolling much faster. Maybe a clear or interpolated area fill could also help.

One can also push compression quite a bit farther.

Another trick that might make VNC appear faster is a multi-window frontend. That way, you don't have to wait for the background to fill in, and small windows have only little overhead.

Re:How useful

[Fnkmaster]

See other comments. Problem isn't so much bandwidth with X apps (especially over DSL line, where you should have plenty of bandwidth), it's latency due to the chattiness of X, i.e. it's tendency to make lots of roundtrips for small chunks of information that have serial interdependencies.

TightVNC vs X

[const_k]

I am developing TightVNC software which features a number of efficient bandwidth optimizations for well-known VNC software suite, and I'd like to share my opinion and experience on low-bandwidth remote desktop solutions. I think TightVNC and future versions of TridiaVNC may be a better alternatives as compared to X in all its flavours (with LBX, DXPC etc.) and I'll try to explain why in the text below. In short, I don't feel much pain using TightVNC over 33.6 Kbps dial-up connection.

Speaking of X and TightVNC, each choice has its specific benefits and drawbacks. First, let's look at strong sides of TightVNC (many points are applicable to the standard VNC, except for the bandwidth usage):

1. TightVNC requires minimum amount of code at the client (user's) side. The client does not require installation and it's size is about 200..300 KBytes. Moreover, you can access any remote system when no native client available: your remote desktop may be accessed from any Java-enabled Web browser, just type the hostname and port number of TightVNC's internal httpd.
2. TightVNC is truly multi-platform in its design and complexity level. Developing a new client is very simple task, the protocol is very simple. There are clients for X and Win32 environments and platform-neutral Java client (only 30 KB of compressed byte code!).
3. TightVNC is better suited for operation in network environment in general. For example, it just skips screen areas that are obsoleted at the moment when a client asks for screen update.
4. TightVNC does not deal with fonts on the client side: therefore it does not depend on font sets on the client system and does not require configuring font servers etc.
5. Compression level in Tight encoder is configurable on the client side and there is a possibility to enable lossy JPEG compression with adjustable image quality. If you don't care about every pixel appearence but just want to get work done, JPEG compression with low image quality level will efficiently use limited bandwidth even on most complex desktop contents.

From my real-life experience, TightVNC session is usually more bandwidth-friendly as compared to X with SSH compression, but X and VNC are very different in their architectures, and there are situations where X is more efficient. And it's not always simple to compare X and VNC.

The main problem of X is its complexity. X was intended to be too flexible and universal by design, but this also means that underlying techniques and protocols are extremely complicated. I often imagine X died under the pressing of it's own complexity. Now about weakness points of the TightVNC:

1. TightVNC always exports the whole screen when X deals with separate windows.
2. VNC was not designed to be secure. There is a number of serious security flaws. X is not perfect in this sense, too, but it's a bit better.
3. Most impressive TightVNC features (local cursor support, JPEG compression, Tight Encoder 1.2) are still in the development phase. While Unix code and Java viewer are ready, Win32 version is not -- there are known bugs at this moment (to be solved in a week).
4. There are problems with internationalization in TightVNC.

Maybe I've forgotten to say something above, but now it's too late and I have to go now.

--
With Best Wishes,
Constantin

Can X be the next big thing?

[pinzari]

This was, actually, the original title. Maybe we are naive, but we think that computers will never be for the mass market until the time they will cost as a TV, a game machine or a cellular phone. I remember when my ZX Spectrum had to battle against Commodore 64 for the premiership. In 80s computers where a mass market phenomenon not more that they are today. PS2 is something I'd pay more attention when we speak about net economy.

In Europe, where mobile telephony is a mass market, nobody cares what OS a telephone is running. The same is true in the US. We think that, soon, nobody will pay attention to the OS a computer does run. BTW, that OS will be Linux, your desktop applications will run unmodified on fbdev and X, and you'll pay a 32MB PDA with 32MB of ROM from which to boot, no HD but a 1Mbps Internet connection 24x7x365 something like 150$. This assumption let us believe server based computing is a real alternative to the PC based architecture which has ruled the world so far.

I read some posts talking about persistence of X connections and resource usage. They were very good points. Infact we are working hard on them. Persistence is not very difficult to achieve, as it's mainly a matter of proxies reconnecting after a network failure. In the future we'll think at 'freezing' X clients and server, the way APMS does. Furthermore we think that the VM technology experimented by VMWare (but also available in Linux as virtual-machines running in user space) are the right complement to make possible thousands of users on the same host. Resource usage at client (X server) side is not that bad already. mlview-dxpc tries to make possible to run full-featured X desktops, as the one you are used to at your -local- machine. I mean with thousands and thousands of bitmap images coming from the net. If you test mlview-dxpc you'll find that a huge amount of bandwidth (and memory) is used by animated GIFs. This is simple to overcome. It's enough an X extension to handle this at the widget-set level. Why nobody has done this before? Because to run a browser on a low bandwidth link was simply not possible, so why bother?

To rewrite an application from scratch is a tough task. This is why Java didn't work and .NET won't. It's much simpler to adapt a stable code base to different conditions. If you have given a look at QT Embedded, you know that most of the KDE compiles smoothly under it. I expect to be possible to configure KDE in the Control Center for slow links in the future (it's enough to disable animations in Konqueror and display a few other things in a different way). I expect also to have at least three different behaviours for your usual GTK and QT applications: X running locally, X running remotely, local framebuffer with low resource usage and small screens. In this future world we'll be able to run agenda or MP3 player on the local PDA and write full featured DOCs and browse the net on the remote machine.

I read a post about a free X not being available on Win32 or platform XYZ. An X server is a network server which translates X protocol in graphic calls that it redirects to the hardware. It's simple to separate the two parts and, actually, this is exactly what Xvnc, XGGI and Xfbdev do. There is already a port of XFree86 for Win32, together with GTK and GNOME desktop. I heard GGI people have compiled it on almost everything from the coffe machine to the Palm and TinyX is now part of XFree86.

One last word about mlview-dxpc's performances compared to other solutions... I think the best is to download and test it yourself.

/Gian Filippo.

another thing to consider....

[brad3378]

Unfortunately, the desktop is not the only thing that needs to be lightweight. I can only imagine how difficult it would be to run the GIMP over a 28.8 connection.

Don't get me wrong though...
I'd be more than happy to have a lighter desktop available.
Besides, a lighter desktop would likely run better on local machines as well.

Re:another thing to consider....

[kesuki]

Unfortunately, the desktop is not the only thing that needs to be lightweight. I can only imagine how difficult it would be to run the GIMP over a 28.8 connection.

The only problem with running Gimp over a 28.8 connection is the latency of a ssh session at that speed. The gimp has full command-line and perl script support. It is very very easy to grab some perl scripts that execute common gimp filters on pictures, then transfer the picture to look at it. you can even generate an entire picture from scratch without ever looking at it with the gimp. Really the gimp is very low bandwith friendly, it's just point and click that doesn't work so well. But really if you were serious about point and click you'd be using a mac G4 running adobe. On a side note you do need an xserver running, but it doesn't have to use a graphic card, any xserver will work.

Re:another thing to consider....

[brad3378]

I'm glad you said something.

I thought that the Gimp (or any graphic intensive app) would have been a good example, but apparently I assumed wrong (again). I would have mentioned a high end Mechanical Engineering Software like I-DEAS but I didn't think many slashdotters would know what I was talking about.

In my own Experience, running I-DEAS can be Incredibly slow over a remote host, and that's even with a limited set of video drivers. The speed sucks, but It's nice to know that it can still be done if you're in a pinch.

You couldn't

[waspleg]

it says it requires 4 Kb/s in the article.. which is like.. 80% of someone's "56k" dialup.. so much for streaming stock prices ;)

X protocol chattiness is the problem not bandwidth

[dbj]

Around 5 years ago I was involved with some people who were trying to determine why their X application was taking 5 to 20 minutes to start up when run across the WAN.

We put some protocol analyzers on it to see what was going on. It turns out that X is extremely chatty. This particular application made over a 1000 round trips between the client and server during start up. When running on a LAN where latency is a milisecond or less this is not a problem, but when running across 15 hops with a latency of around 300ms the chattiness blows up in your face.

If the latency is low, X's bandwidth requirements are very modest. I used to run an X terminal on a 14.4Kbs modem to telecommute and while it was a bit slow it was usable.

To make X a WAN friendly protocol someone needs to address this chattiness issue.

David

RDP client for Terminal Server available under GPL

[Jacco de Leeuw]

Remember the DM 30.000 reward for a GPL'd client implementation of RDP?

RDP is the thin client protocol used by Windows NT Terminal Server and Windows 2000. Well, you guys might be interested to know that Samba team member Matt Chapman has done it.

rdesktop is available on the rdesktop website and only supports NT4 and 8-bit screens. Since then, patches have been made by several people, which extend the support to Windows 2000 and 16-bit screens. Get the "unified patched" version from Peter Bystrom's site instead.

This is of course great news if you previously were forced to use a Windows RDP client on the desktop to access your (corporate) Windows network. You could even make a very inexpensive thin Linux client with RDP, VNC and Low-bandwidth X support.

I don't know if Matt actually got the reward. The German company IGEL might as well have caved in and bought a licence from Microsoft, since they are now offering products containing RDP support.

Jacco (to e-mail me, please remove all yourclothes)
---
# cd /var/log

Free X server for Win32 from RedHat

[johnnyb]

RedHat is doing a Win32 port of X. See the scoop at

http://sources.redhat.com/win32-x11/

and

http://sources.redhat.com/cygwin/xfree/

These actually may be the same project. Says it runs on Windows 95, Windows 98, and Windows NT. I expect it would run on Windows 2000 as well.

Re:How useful

[shepd]

>Honestly, everyone is going to have high-bandwidth connections in a few years

They said that about personal phone lines. The government still makes exceptions for Bell to allow them to continue servicing existing party lines; These lines are not listed as a required upgrade.

It took decades for Touch Tone to become ubiquitous enough for companies to get rid of phone operators; Yet still, I know people who do not have Touch Tone lines today.

How many of you are still unable to get a telex line? This is such old technology you should be able to get one on sealand! Yet it is unavailiable to many.

How about centrex/leased line service? This may be unbelieveable to some (considering the profits built into these lines) but geographically I've found many people, even those in 1st world countries, cannot even get this 60's (maybe 40's?) tech!

Does pager service yet cover your entire country? Do cellphones work once you leave city limits?

When it comes to Bell, "I'll Beleive It When I Have It!" (even then, I'll be checking my service daily to see if Bell changed their minds).

Grunge dropping New Jack through a press table

[Graymalkin]

Running X over a low bandwidth or high latency connection is asking for trouble. You might get a static desktop up and runing fine on a Yopy or some little toy but if you run something even mildly intensive on the graphics (say Gimp for instance) you're not going to be very happy with performance. Not only does it have to send an updated screen for every filter or change to make to an image you also have little things like the animated border around a selection. I used to connection to the SPARC stations at my friend's school over the internet and it was a drag even with a cable modem. Most recent X apps are not designed with bandwidth skimping in mind, they're designed like Windows and Apple apps. You get spoiled when you start making apps people use only on their local desktops whereas app engineers 15 years ago would go to the greatest pains to skimp on bandwidth as no one ran X on a desktop machine. X has VERY little to do with .NET or low level RPC frameworks. X provides communication between top level components over the network (such as the GUI) whereas CORBA, COM+, ect. provide network access to lower level components. .NET and any framework like is much better suited for accessing remote program components. You can use SOAP to communicate with an Apache or IIS module through HTTP transfering only a couple objects as XML documents where X is transfering lots of widget descriptors and frame images.

Re:Grunge dropping New Jack through a press table

[pinzari]

It was far from me to say X = .NET or X = Java. Actually I didn't say that. I said Java and .NET (or JavaScript) are all technologies their proponents have tried to push on your client and, hence, on your desktop.

They (of course) have many advantages over X (you mean ICE, I guess ;-) to run client/server, distributed apps. Infact you can use CORBA, BONOBO, XML-RPC, KParts or DCOM to distribute application's intelligence and use X to display it.

The problem, in my opinion, is if it's worth the pain to download a VM, a runtime environment and the component itself on the client to let it draw the screen, or is better to leave them at home and use X_PolyFillRectangles.

/Gian Filippo.

X isnt as popular as Video (mpeg4/divx)

[BrookHarty]

If there was as much interest in X/VNC as streaming video, we wouldnt be having this discussion.

And yes, I currently use X/SSH over a 56K link, works fine for multiple xterms and some netscape guis.

DXPC, lbxproxy and SSH compression

[SWroclawski]

There are several programs for this.

lbxproxy works with X. Part of it actually comes with XFree86.

DXPC is an oldie but goodie. It requires you to use it on both server and client end though.

And good old SSH compression is usually good enough. Turn on X forwarding, turn up the compressiona and usually you're good to go.

I haven't found VNC to be very good for bandwidth, but you might want to try a VNC compressor like this.

- Serge Wroclawski

another cool use.......

[brad3378]

Get one of those "linux TVs" from Yesterdays Slashdot article and use it as a way to run your network apps on a huge monitor. If network latency wasn't a problem, you'd have a sweet monitor to play games on.

Read the link

[Arker]

Geez, read the link before you post, people. This isn't a lightweight desktop, it's a module for compression X protocol traffic. That's the big problem with running remote X sessions - they eat bandwidth like nothing else.

Fortunately it's also quite compressible. By optimising compression for the protocol, they're claiming to average 60:1 compression, making it possible to run a full-on X session on a 64k link... yummy.

"That old saw about the early bird just goes to show that the worm should have stayed in bed."

trying to compile this thing..

[ikekrull]

It says it needs the LZO library..

so i run off to rpmfind.net and install lzo-1.06-1-i386.rpm.

And configure still barfs saying it can't find the library.

liblzo.so.1 and the symlink liblzo.so.1.0.0 are plainly visible in /usr/lib.

Do i need a different library, to install it in a different place, or what?

I'm not a linux newbie, but this kind of thing frustrates the sh*t out of me.. i'm all for source distributions, but this has happened lots of times. Most of the stuff i have compiled builds fine, but theres always the one package you want that just refuses to compile, even though the libraries it wants are supposedly installed.

Can anyone give me a pointer to some resources that explain just how i should go about troubleshooting this type of problem?

Re:trying to compile this thing..

[TwinSpark]

What you need to compile mlview is lzo-devel library,
not just lzo.
BTW, it is true with most programs: you need xxx library
to run them, and xxx-devel to compile.

LBX is useble at 128kbit/s

[Baki]

From my work I can reach my home at 64kbit/s. First I tried X, but it ran too slow. Then VNC: too slow either, it seems to send the whole screen as a huge (compressed) bitmap.

LBX though is somewhat usable at 64, and really usable at 128kbit/s. I don't see how VNC could be a match for LBX. Also VNC somehow looks very ugly (probably a fonts problem).

X in itself is well designed for low bandwidth use, since it doesn't send the screen (or parts thereof) as bitmaps, but only sends graphics primitives (draw line, draw rect etc). LBX adds compression of events, omision of non-essential events and also (if you want) stream compression (I don't use it since I run LBX over a compressed SSH stream).

Remote X Apps mini-HOWTO

[Alien54]

As also noted in the article, there is this link to the Remote X Apps mini-HOWTO.

As it says: "This document has been written with unix-like systems in mind. If either your local or remote operating system are of another flavour, you may find here how things work. However, you will have to translate examples yourself to apply to your own system(s)."

Side Note: There is also the issue of security on this that is mentioned in several places. Given the projected use of this, security becomes rather important.