Slashdot Mirror
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."
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.)
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.
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.
I'm a loner Dottie, a Rebel.
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
no sig.
This works great.. i feel dumb now :)
Thanks
I gots ta ding a ding dang my dang a long ling long
Well, we actually use Citrix+MS Terminal Server in work too. And by god does that absolutely suck.
/really/ well - its a lot faster than citrix/TS on a LAN.
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
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.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
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:
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.
--
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:
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.
Will I retire or break 10K?
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).
Eh...
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?
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 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!
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).
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.
read the article again.
This is not a TV
It's a monitor with Television hardware.
There's a huge difference!
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.
The low level implementation of X programs requires a linear flow of
, 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.
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?
__________________
- 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.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!
Only 'flamers' flame!
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):
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:
Maybe I've forgotten to say something above, but now it's too late and I have to go now.
--
With Best Wishes,
Constantin
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.
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.
If they get this working, could be fun."It is a greater offense to steal men's labor, than their clothes"
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.
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 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) /var/log
---
# cd
-------
Warning: Slashdot may contain traces of nuts.
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.
Engineering and the Ultimate
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'm a loner Dottie, a Rebel.
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
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.
"It is a greater offense to steal men's labor, than their clothes"
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."
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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.