Posted Nov 8, 2010 16:19 UTC (Mon) by foom (subscriber, #14868)
In reply to: LPC: Life after X by marcH
Parent article: LPC: Life after X
Except, as many people have pointed out already: if X applications don't care about working remotely, then they *DONT*, because they do too many round-trips, which becomes deadly over a network with more than a few ms RTT. I have tried to use X remotely a few times, but it simply isn't usable for most things other than emacs and xterm.
The "transparency" feature of X needs a lot of work...
Posted Nov 8, 2010 17:07 UTC (Mon) by marcH (subscriber, #57642)
[Link]
> if X applications don't care about working remotely, then they *DONT*, because they do too many round-trips, [...] I have tried to use X remotely a few times, but it simply isn't usable for most things other than emacs and xterm.
On a LAN this is just plain wrong.
Not so long ago people working with dumb X11 terminals on Ethernet 10M. For sure they were not playing games nor using Eclipse; that does not mean they were using only emacs and xterm.
Not later than this morning I used this over encrypted (!) X11 forwarding: http://www.methylblue.com/filelight/
It worked like a charm, just like thousands of other X11 applications. Out of curiosity I just tried: gimp, firefox, and OpenOffice and they all work flawlessly on my LAN. I did not even had to get rid of the encryption!
The reason why X11's networking is not so much in use nowadays is just because a powerful PC is now cheaper than a dumb X11 terminal. It is NOT because every single X11 framework is badly designed and wasting thousands of round trip times and cheap CPU cycles.
For sure there are plenty of cases where X11 networking is irrelevant. There are ALSO plenty of cases where it works perfectly thank you very much.
LPC: Life after X
Posted Nov 8, 2010 17:41 UTC (Mon) by droundy (subscriber, #4559)
[Link]
The problem is that applications (and toolkits, antialiasing, etc) have bloated the number of round-trips required. In my (admittedly anecdotal) experience, modern applications (including a current emacs) run *way* slower over a network than similar programs did in the 1980s. Everything has been designed and optimized based on the assumption that the X server is on the same machine as the client.
LPC: Life after X
Posted Nov 8, 2010 18:30 UTC (Mon) by drag (subscriber, #31333)
[Link]
This is because that is always true that the client is on the same machine as the server. Within a error of about .1%.
LPC: Life after X
Posted Nov 20, 2010 1:04 UTC (Sat) by Wol (guest, #4433)
[Link]
Actually, in my house, that's true about 50% of the time.
Soon, probably, to be 33% of the time ... :-)
(I've got a Phenom X3 as my main machine, an Athlon 1050 .75Gb ram machine I use as an x-terminal, and an Acer Aspire One that will probably soon have Smeegol on it and get used as an x-terminal too)
Cheers,
Wol
LPC: Life after X
Posted Nov 8, 2010 20:21 UTC (Mon) by foom (subscriber, #14868)
[Link]
>> if X applications don't care about working remotely, then they *DONT*, because they do too many round-trips, [...] I have tried to use X remotely a few times, but it simply isn't usable for most things other than emacs and xterm.
> On a LAN this is just plain wrong.
Thanks for the creative editing.
Let me fill in the "[...]" you snipped out of my original message:
>which becomes deadly over a network with more than a few ms RTT
Hey, guess what! On a LAN, you won't have more than a few ms RTT!
Now try running those apps when you're working at home, a few miles away real-space, and 50ms away RTT.
LPC: Life after X
Posted Nov 8, 2010 21:54 UTC (Mon) by marcH (subscriber, #57642)
[Link]
My bad I honestly missed that. Sorry.
Even if X11 networking is or has become unusable on the WAN it is does not really matter: it still works very well on the LAN so it can absolutely not be dismissed as if it were a forgotten thing from the past.
LPC: Life after X
Posted Nov 22, 2010 5:59 UTC (Mon) by dododge (subscriber, #2870)
[Link]
Here's a real example from the 10MB days: early web browsers often had their their application logo at the top corner of the window, and would run a little animation loop when loading a page. I believe in Netscape's case it would send the entire logo image to the X server for every frame of animation. This worked fine on the same machine because it could use things like XSHM to send the image data out-of-band, but when running remotely it meant it was continuously and repeatedly encoding and transmitting each frame of the animation through the X protocol.
If they had designed for network transparency they presumably would instead have cached the frames as a handful of server-side pixmaps and flipped between them. It seems like a little thing, but as I recall this minor oversight made it perform terribly over a LAN.
LPC: Life after X
Posted Nov 22, 2010 8:18 UTC (Mon) by nix (subscriber, #2304)
[Link]
IIRC this was only true in Netscape 4, which is when Netscape decided to give the implementation job to a gang of crack-addled monkeys rather than JWZ. (I think that was his phrase...)
Quality suffered accordingly.
LPC: Life after X
Posted Nov 22, 2010 10:56 UTC (Mon) by dododge (subscriber, #2870)
[Link]
Yeah NS3 or NS4 sounds about the right timeframe. I mostly remember noticing that it was much slower than it should have been and having a real WTF?! moment when I traced the X connection and saw all those images flying by.