Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
X GUI

Low-Bandwidth X 145

Posted by michael from the coming-next:-low-cpu-X dept.
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."
This discussion has been archived. No new comments can be posted.

Low-Bandwidth X More

Low-Bandwidth X

Comments Filter:
  • 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"

  • 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.

  • 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.

  • 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.

  • ldconfig

    The linker keeps a cache of the libraries it has, you need to rebuild the cache when you add libraries.
  • 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

  • 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 [tridiavnc.com] and scour ftp://ftp.yggdrasil.com [yggdrasil.com].

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

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

    ===

  • 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... (Score:1)

    by 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 (Score:1)

    by floki ( 48060 )
    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?
  • I have no idea.

    must be that randomness M$ puts in to all it's products that decides how well (if? ;P) it works....
  • 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*
  • 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:How useful (Score:3)

    by Jeremy Erwin ( 2054 ) on Sunday March 11, 2001 @05:54AM (#371188) Journal
    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.
  • 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.

    ----
  • 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)
  • See here. [sun.com] for the Sun Ray series of products. I've used them before -- they're really quite nice.
  • 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.
    --
  • using a browser based solution like thinwireless.com, and a phone with a java browser and gprs it maybe could be done
  • 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..

  • VNC with TIGHT ENCODING is what you need. (Score:1)

    by 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 (Score:1)

    by wik ( 10258 )
    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.

  • 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 (Score:3)

    by perlyking ( 198166 ) on Sunday March 11, 2001 @04:54AM (#371198) Homepage
    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
  • This works great.. i feel dumb now :)

    Thanks

  • 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.
  • 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 ?

  • You should be happy with your local Slashdot server, why view such a thing remotely ?
  • 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.)
  • 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.
  • 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
    --

  • Still no support for resumable desktops (Score:4)

    by ideut ( 240078 ) on Sunday March 11, 2001 @06:24AM (#371206)
    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.

  • 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.
  • 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 [freshmeat.net] 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.
  • Gosh. What a coincidence (see my comment [slashdot.org] 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?
  • 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.'"
  • 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.
  • #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!!

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

    Not when a site is slashdotted within five minutes [slashdot.org] 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 [pineight.com] are belong to us.
  • 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?
  • How fuck'ed up is it on a scale from 1 to 2 to have a .com website in itallian?!?

    -H
  • 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).

  • 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.
  • 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.
    ___
  • 1 .Use my same desktop from anywhere in the house
    2. Access my home's desktop from the computer laboratory in town

    x0rfbserver [hexonet.de]. A Unix/Linux VNC server that acts like a Windows one, where the remote user takes over the desktop.
  • 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
  • Check it out here [cctpu.edu.ru]! Much better than ssh+compression or anything else I tried with VNC.
    Bye egghat
  • 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.

    ----

  • 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..)

  • Re:VNC (Score:3)

    by Ed Avis ( 5917 ) <ed@membled.com> on Sunday March 11, 2001 @06:48AM (#371224) Homepage
    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.
  • 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:Still no support for resumable desktops (Score:4)

    by garrettl ( 171673 ) on Sunday March 11, 2001 @06:50AM (#371226) Homepage

    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/ [columbia.edu]

    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 [msu.edu] 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. (:

  • Check out WeirdX [jcraft.com]. It's hosted on SourceForge [sourceforge.net] and also has a project page on Freshmeat [freshmeat.net].

    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. (:

  • 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?
  • 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.

  • > 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.

  • 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!

  • 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).

  • 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:Why remote? (Score:3)

    by cyberdonny ( 46462 ) on Sunday March 11, 2001 @07:03PM (#371234)
    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?
  • 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.

    ===

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

    The US has a .us domain, it's just that few use it.
  • read the article again.

    This is not a TV
    It's a monitor with Television hardware.
    There's a huge difference!
  • 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.
  • 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 (Score:5)

    by tessellation ( 133537 ) on Sunday March 11, 2001 @07:22AM (#371240)
    anyone interested in using remote desktops over IP networks ought to take a look at TightVNC [tightvnc.com], 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.
  • That's 4Kb/s, KiloBITS, not KiloBYTES. I think a 56 Kilobit connection could easily handle 4 Kilobits.


    Enigma
  • 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.
  • 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?
  • 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
  • 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... (Score:3)

    by a_hofmann ( 253827 ) on Sunday March 11, 2001 @09:07AM (#371246) Homepage
    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.

  • 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?
  • Go to http://www.tightvnc.com [tightvnc.com]. They're doing some clever things to make bandwidth MUCH less of an issue. (Including lossy jpeg sessions if desired.)
  • I don't know about low bandwidth but over my 100Mbps LAN Hextile is the best
    .oO0Oo.
  • 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
  • Consider the popularity of pseudo-thin client technology, such as Citrix [citrix.com] and Sun Ray [sun.com]. 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?

    __________________

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

  • 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.
  • 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:VNC (Score:2)

    by mpe ( 36238 )
    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"
  • 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.

  • TightVNC vs X (Score:4)

    by const_k ( 140010 ) on Sunday March 11, 2001 @10:08AM (#371273) Homepage

    I am developing TightVNC [tightvnc.com] 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 [tridiavnc.com] 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

  • 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.

  • 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.

  • 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.
  • 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."
  • 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
  • Remember the DM 30.000 reward [slashdot.org] 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 [rdesktop.org] 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 [bibl4.oru.se] 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 [www.igel.de] 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

  • 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.

  • Grunge dropping New Jack through a press table (Score:3)

    by Graymalkin ( 13732 ) on Sunday March 11, 2001 @10:48AM (#371295)
    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.

  • 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.

  • 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 (Score:3)

    by bencc99 ( 100555 ) on Sunday March 11, 2001 @05:06AM (#371302) Homepage
    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.
  • There are several programs for this.

    lbxproxy [hp.com] works with X. Part of it actually comes with XFree86.

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

    And good old SSH [openssh.com] 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 [pagecreator.com].

    - Serge Wroclawski
  • 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.

  • Read the link (Score:3)

    by Arker ( 91948 ) on Sunday March 11, 2001 @05:15AM (#371307) Homepage

    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."

  • LBX is useble at 128kbit/s (Score:3)

    by Baki ( 72515 ) on Sunday March 11, 2001 @11:31AM (#371310)
    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).

  • 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.

  • 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.

Slashdot Top Deals

"The voters have spoken, the bastards..." -- unknown

Close