Slashdot Mirror

The X11 folks tried to fix that by creating Low-Bandwidth X (LBX), which may be what you're thinking of. It never really took off, both because it didn't really help much and few commercial Unix vendors (remember them?) bothered to implement it.

Nah, he probably just got his acronyms mixed up. My bet is he really meant the Differential X Protocol Compressor, or DXCP for short. DXCP would be the precursor technology that lead to NX.

I've done X over a 28.8k modem. It was ugly.

Moving to 128kbps ISDN made things hugely better. Using SSH compression was better still. And differential X was fairly usable with lots of X11 software at the time.

But in reading this announcement, I can't help but think: Isn't this the same as Broadway? It seems that it was released along with X11R6.3, which Wikipedia says went public on December 23, 1996. Wikipedia's article on XFree86 also implies that it should've been in the hands of Linux users sometime on or before March 8, 2000, when the 4.0 release of XFree86 went public, which was supposed to support X11R6.4.

But: Nobody, as far as I can tell, ever used the silly thing, despite all of the flowery claims about how cool it'd be to run X over teh Intarwebs, having finally solved the latency and bandwidth problems by introducing a standard made to deal with them from the outset.

So, here we are in 2009, about 12 years hence: Can anyone explain to me why this "new" NX Server concept should be any more successful than Broadway? Is it just because we're a decade ahead, now? (Or is that a decade behind?)

I was looking at molecular models on our workstation at the lab, from home, over a modem line in the nineties. Nobody ever thought of giving me my own workstation and $25000 worth of MM software (*sniff*) or making me pay for one (luckily..). Instead I got by on a i386 (a real one) with 4 Mb memory and a 14 inch color screen. It was dead slow, but doable. Biggest problem was that my screen at home didn't have 32-bit color depth but 8-bit.

If those students have to acquire their own copy of such heavyweight modelling software instead of just using it at the lab (from wherever the students themselves are located at that moment) then I think that university shows some serious neglect of 1987's state of the art of utilizing windowing systems for end-users in a network-transparent way.

Students who don't know Linux exists and can be used as an X terminal could be excused in, say, 1994, but that's hardly an excuse anymore. And sure, it puts a much higher load on the internet's tubes, but those have improved in the meantime as well, and clever people thought about compressing the protocol. And you can easily tunnel X over ssh.

I mean COME ON, if a problem is that expensive, nobody tried to find a solution? wtf?. </rant>

Rule of Modularity: the 'simple parts' are not so simple- take any linux distribution and type 'man ls' and see how long that is, it will work for anything substituted for ls, certainly not simple.

The unix philosophy is One tool does one task, and does it well. ls lists the contents of a directory. There are some options for sorting and selecting what information to show. But it's still just listing the contents of a directory. If ls also checked your email (jwz's rule) or something like that, you'd have a point. But you don't. You're just confusing options and complexity.

Rule of Composition: Most new linux apps are not desined to be connected (through a pipe) to anything else-- they are either programs written with curses or for X and that means that they are not connectable.

Don't confuse applications and tools. Apps are big monolithic programs like web browsers and media players. The little unix tools that populate /bin and /usr/bin are the things that are meant to be used with pipes and other shell constructs. It doesn't usually make sense to pipe the output of an app to much besides a log file.

And a pipe doesn't always have to be STDOUT or something. When working locally X11 goes through a pipe, a named pipe. DXPC, the Differential X Protocol Compressor, uses named pipes to send X11 messages to another host in an efficient compressed form. This program doesn't need to modify X or libx11 or anything else to do what it does. It's all through the magic of pipes!
(I originally thought SSH used the same method to forward+compress+encrypt X11 traffic, but it looks like it binds on local TCP ports instead)

Rule of Parsimony: use ls -l /path/to/program of ls -R /path/to/source and check the size column. Or check the man page. Or start the program and look. There are not many small linux programs- especially because of its open-source nature. Linux (kernel) itself is also pretty big,

Boy, you're not making much sense there. The linux kernel is actually pretty small. Most apps are quite a deal larger than the kernel. My 2.6.7 kernel here is 1.3M, compressed. My XFree86 4.3.0 X server is 1.7M. Mozilla is close to 20M. And ls, your previous "complex" example, is all of 71K. Apps are big, tools are small. On any OS. Simple.

In case anyone is fooled by the baseless criticisms of X given by the regular troll above, here is a brief rebuttal.

• "1.Too much focused on 2D user interfaces, no native transperency for multimedia, low level and optimized applications."

Most major computer operating systems have 2d user-interfaces, but this doesn't matter because applications provide their own 3d user-interface if they really need one. Another reason may be that there are very few genuine 2D users who can satisfactorily project themselves onto a 3d user interface. Transparency is not a major requirement for X because those rare applications which require it can implement it themselves e.g. using GIF or PNG transparency. There is also going to be a transparency extension for X

• "2.Too little scalability between devices with varing performance and ability."

Not true. X runs fast, and much faster than Microsoft Windows 95, on my old i486 PC with 8MB RAM.

• "3.No sufficient support for disabled user enhanching devices."

This is a problem not of X itself but of the hardware manufacturers not writing device driver modules for XFree86. When enough people run Linux desktops in the opinion of the hardware manufacturers, device drivers for XFree86 will be written.

• "4.Severe security issues in the protocol. Especially no encrypted operation at NATO standard SECPROT level 4."

This has been nominated for Top 10 Absurd Comments on Slashdot. With a properly configured firewall, this is irrelevant because nobody on the internet can attack your computer's X display. By using ssh for securely forwarding X11 connections most attackers will be unable either to watch or to disrupt your X session.

• "5.Network protocol too bloated and complicated."

Very few people ever use the X11 protocol over a network, firstly, because most people who use X are using it for X applications running locally on their desktop computer, and, secondly, because anyone wanting to run X applications on a remote computer would use an X11 protocol compressor. The X11 protocol is complicated because it is powerful and easily extensible. As an aside, most intelligent people don't seem to have much trouble understanding the X11 protocol or the various extensions.

• "6.No smooth integration into the operating system."

That would be a very bad idea. Increasing the complexity of the interfaces between vital system components such as the kernel and X is a recipe for worse security, worse compatibility, and worse maintainability.

• "7.No smooth integration of the window managers."

Integration with what? X? The whole point of separating window management from X is to give you the freedom of choice to use whichever window manager you like. You can even change the window manager without having to reboot the kernel or re-start X. Otherwise, if you don't like using window managers, use GNOME, or KDE, or return to MS-Windows.

• "8.No stream compression in the protocols."

You don't seem to have heard of NX for real-time X11 protocol compression which typically achieves a 1000:1 compression ratio, of the ancient LBX, or of Differential X Compressor

Another product that's been around for a while and works pretty good is Differential X Protocol Compressor. How does this new product differ?

So how is this different from what DXPC does already? Faster, better? Niftier logo? http://www.vigor.nu/dxpc/ I used dxpc years ago when I had a slow connection. Worked great, as soon as you figured out the tricky bits when combining with SSH and tunnels over multiple nodes. TA (no connection with dxpc other than as former user)

Some reasons why X is not a good idea in this case:

1. Plain X protocol doesn't work well with high-latency connections (like a 56k dialup connection): it's the best thing since sliced bread in a LAN, it employs several tecniques to save bandwidth, but unfortunately apps have to continuosly talk with the X server and latencies play a big role. IMHO this is expecially true with modern (read: relatively young) toolkits like Qt or GTK+, which probably could do better at keeping the number of requests to the X server to a minimum (note: the number, not the size). Of course, there is the Low Bandwidth extension to X (LBX, to be used via lbxproxy, and the Differential X Protocol Compressor dxpc which, aside from compression, employs some caching to avoid contacting the X server on the other side when it is not absolutely necessary (thus making latency less of a problem).
2. The X session is fragile: dialup connections tend to go down unexpectedly, and in such cases your X session is abruptly closed. For each connected client (application on the application server), the X server keeps a lot of state which isn't saved. If the link goes down, you can't reconnect later and find your session again (or, for the same reason, transparently move an app from one X server to another - even if there are some tricks about the subject)

For these two reasons, VNC seems to be a better idea in this case.

There's also the Differential X Protocol Compressor DXPC. I don't know how it compares to LBX, but it's certainly an option to look at.

I won't speak to raw performance issues here, but the network load of the X protocol can be greatly alleviated by dxpc or better yet MLview dxpc, which claims to be around the speed of Citrix ICA.

In the past, I've used dxpc for broadband-speed X connections, and while it didn't solve all of my problems, it did make them more bearable. These guys have done lots of work on improving dxpc, and I highly recommend it.

(Latency, however, will kill you. I wish I still had the DSL connection I had at the old apartment; it ran circles around this cable modem.)

http://www.vigor.nu/dxpc/

I'm not saying the dxpc approach is optimal, or good design. I don't know much about X event streams, but it does seem like higher-level operations are appropriate. The thing that X gets right is the assumption that all transactions will be over a network.

It's now three years later, XFree86 4.x is looking completely stable, along with LBX, RX, and a slew of other things that nobody ever uses. It is uncertain to me whether or not it will ever make a difference, at this point. At the time of LBX's birthing (early 1998), bandwidth was nearly nonexistant for everyone, and such a thing made sense for a great number of people.

That said, I'd like to use LBX. I want to run [gnutella|napster|mojonation|freenet] on a high-bandwidth linux box with a DDS-2 drive, while sitting at home behind a trio of 28.8 modems (ie, "As Good As It Gets In Rural Ohio"). Never underestimate the bandwidth of a Chevy Beretta filled to the brim with DAT carts.

I've used differential X (dxpc) with some success, but it uses particularly ugly methods of interfacing with the client software, and requires being set up before each session. I've also used ssh's gzip compression and X11 forwarding, which isn't anywhere near as fast, but is at least transparent in use.

LBX and RX/Broadway would seem to serve both purposes admirably. Too bad that in this chicken/egg scenario, the bird just won't lay any eggs.

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

X is not the best in every situation, but if with "bloated" you mean "large bandwidth", I'd suggest you having a look at dxpc (Differential X Protol Compression).

If with "bloated" you mean it has a complex low-level API because of backwards compatiblity, well, it may be the case. But unless you are a toolkit developer, this shouldn't affect you

On the other end, if you just want ICA, you can buy Metaframe for Solaris from Citrix. But probably is not what you want.

The problem with X is that it usually is good enough (i.e. office applications on a 10Mbps LAN) and it can be extended, so competitors have to work really hard just to catch up.

There is also a large set of X application out there that must be supported, so a replacement should really also provide X compatibility (i.e. at least with a gateway X -> other protocol, like VNC server on *NIX).

Even sending changes in terms of rectangles (or whatever) of pixels is quite expensive, mainly because you have to look at what the changes are in the first place (the graphic engine of the underlying platform may be of great help here).

Although VNC is a Good Thing(TM) when the server runs on a *NIX machine, there are more mature (in terms of performance) products to remotely display Windows applications (i.e. PCAnywhere). VNC people acknowledge this, saying that there is large space for improvements.

But if you need only to run remote X applications and have an X server, a really good solution is compressed X protocol: see the LBX-HOWTO and DXPC in particular (the link in the HOWTO is outdated). With dxpc, 128kbps should be really more than enough for everyday's needs (unless you have to play Quake, of course, or watch a DVD...).

Now, what I'd really like to see is something supporting both this and ICA (and perhaps some local apps in ROM/Flash, since the thing necessarily needs some processing power and RAM in any case).

I also know an answer is "shut up, buy yourself a laptop with 802.11, install Linux on it and on your box in the basement", but a device having a only a compact flash slot (instead of hard disk/floppy/cdrom/etc.) and keyboardless (if you have to type extensively, better go to a desktop anyway) would be IMHO a better (and possibly cheaper?) solution.