7 ms·

This was a solved problem 30 years ago in the Unix and later Linux worlds. Completely remote X based terminals/thin clients were quite common. My impression i

This was a solved problem 30 years ago in the Unix and later Linux worlds. Completely remote X based terminals/thin clients were quite common. My impression is that things have mostly regressed since then, probably due to neglect since it's a kind of functionality that not many people seem to be interested in these days.

znpy 4y ago
Yes it was but the thing is that the problem to solve then got harder. Think about video streaming, 3d acceleration, sound input and output. Then whereas you previously had only a handful of vendors to coerce into agreement, now you have a multitude of individuals that are going to complain for every change.
kllrnohj 4y ago
> probably due to neglect Kinda yes kinda no? Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. So everyone draws stuff on their own, since it's far more flexible and faster. Same is true on windows. RDP is streaming video far more often than it steams drawing commands. You could maybe build something that streams GPU commands, though. Use something like VirtIO-GPU + GFXSTREAM ( https://www.phoronix.com/news/VirtIO-Context-Type https://www.phoronix.com/news/VirtIO-Context-Type ) to stream to an entirely different computer instead of just to the VM host?
- PaulDavisThe1st 4y ago
  > Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits. The two things that have changed are the underlying GPU technology, which has shifted towards abstractions and APIs mostly targetting gaming and video, and desktop level UI stuff, which is expected to include compositing these days. However, it's not as if the other remote desktop systems have really changed much to reflect these developments either.
  - kllrnohj 4y ago
    > This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits. This is really fundamentally wrong. Nobody has been updating X commands for modern effects (eg, blurs, advanced blend modes, etc..). Heck you can't even do round-rect clipping. You have to generate a clip mask pixmap instead. At which point I might as well just generate the final pixmap and forget about X anything. Especially since xlib doesn't even do anti aliasing. Like come the fuck on, it's friggin useless. Can't even handle text adequately! There's a reason Wayland dumped it all entirely. If it had been maintained and updated sure maybe. But it wasn't. It's a drawing library straight out of the 90s, absolute abandonware
    - PaulDavisThe1st 4y ago
      Well, on the one hand, you're right. But on the other hand, X is still being used to do all that stuff (not necessarily using the body of its drawing command set). So even if X's drawing commands themselves are less relevant than they once were, X itself is still entirely capable of presenting GUIs with blurs, anti-aliased text etc. etc.
      - kllrnohj 4y ago
        Well sure but it's just compositing pixmaps from somewhere else. It's just a bad compositor at this point
- renox 4y ago
  > so everyone draws stuff on their own, since it's far more flexible and faster Faster for which usage? Locally yes, but not remotely where it's worse.. In the beginning Unix desktops were optimised for LAN, and in the process of being optimised for standalone PCs to the dismay off those who access their Linux desktop remotely..
  - kllrnohj 4y ago
    > Faster for which usage? Locally yes, but not remotely where it's worse.. How do you know it's actually worse for remote? I can render my entire UI on the GPU & route that straight into a video encoder incredibly quickly. Faster than XLib can draw in the first place. Now there's the bandwidth question there yeah. The video stream takes X Mbps, and the Xlib stream takes Y Mbps. Unless you've measured it recently, you don't actually know if X or Y is smaller. You can make a guess that xlibs is smaller, sure. After all it's vector, right? Except it isn't, not really. Text is all pixmaps. Images are all pixmaps. Path clipping is all pixmaps. Are you compressing all those pixmaps before sending? If so, to what? And is that faster than your GPUs h264 encoder? Almost certainly not. Is it smaller? Also probably not really. And I don't know about you, but I got way more bandwidth than I have latency for my Internet connection. So whether or not X or Y is smaller doesn't actually matter to me. What matters is which gives me less end to end latency, which all but certainly is the video encoder & decoder path, which are incredibly well optimized and hardware accelerated.
    - yjftsjthsd-h 4y ago
      > How do you know it's actually worse for remote? Because I've tried `ssh -X` and in my experience it sucks for any "modern" program (that I've used; I suppose there's bias in my sample).
- jcelerier 4y ago
  "everyone" is just not true, Qt apps can still send X11 draw commands
  - tinus_hn 4y ago
    You can easily draw any desktop with X11 draw commands. They’ll just be Blit Blit Blit Blit Blit Blit Blit The x11 commands allow you to draw lines, ugly patterns, ugly fonts and blit pixmaps. All of them except blitting pixmaps are basically not useful for a modern desktop.
    - jcelerier 4y ago
      This is literally false for Qt. Here's the code: https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/xcb/nativepainting/qpaintengine_x11.cpp#L943 https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/... Here's e.g. dolphin rendered with it here over ssh: https://imgur.com/bLnop55 https://imgur.com/bLnop55 > All of them except blitting pixmaps are basically not useful for a modern desktop. that's ridiculous. Most software is basically a succession of drawLines / drawRect calls with the occasional pixmap.
      - kllrnohj 4y ago
        How much of that dolphin UI is hitting X drawing commands, which appears from your source link to be the simple case only, and how many are rendered to pixmaps and only composited by X? All of the text, for example, is rendered by QT and sent as pixmaps. The drawTextItem path doesn't ever attempt to use XDrawText
        jcelerier 4y ago
        What simple case ? Every call to drawRect/drawLine that I can see at a glance will end up inside X functions - e.g. calls to QPaintEngine::drawRects will just end up in the function below. And that's the huge majority of the UI. Anyways, what matters to me is that I can resize the window without any lag and compression - it immediately becomes much more laggy and redraw-artefact-y if I disable X11 painting when I access my remote machines so it's pretty obvious when things are using it
II2II 4y ago
Is it a case of people not being interested in the functionality, or a case of the functionality being so poor that people don't want to use it. I remember using X to run applications from half way across North America about 20 years ago. To be specific, I remember using it to do image editing in Gimp. Performance was great. Heck, I even used it over dial-up connections to my university. For some X applications performance was fine, though I was clearly using it for less demanding software. Of course, expectations have changed. Microsoft has acknowledged this by continuing to improve upon Remote Desktop. I love and use the feature, even though I cannot stand Windows. While I use a couple of X applications over the network, for the most part I don't even bother. It's finicky to get working. Even when the fiddly bits are set up properly, there is no guarantee the software will work.
- PaulDavisThe1st 4y ago
  > It's finicky to get working. ssh -Y remote-host ... % x-application-name What's finicky?
  - deleted 4y ago
    [deleted]
  - II2II 4y ago
    I can't remember the details, just that I had to setup access control and environment variables.
    - PaulDavisThe1st 4y ago
      That's precisely what ssh -Y or ssh -X do for you.
- noAnswer 4y ago
  Are you sure you remember it correct? I specificity remember tests we did over ISDN (64kbit/s). Opening KMail (X forwarded over SSH) and rendering changes took several 10s of seconds. There is a reason NoMachine and X2Go got invented.
toast0 4y ago
> probably due to neglect since it's a kind of functionality that not many people seem to be interested in these days X11 is at its heart an asyncrhonous distributed systems protocol (quite similar to Erlang Dist) that happens to output to the screen as a side effect, but a lot of libraries and toolkits (including xlib) provide synchronous abstractions on top. When applications use synchronous abstractions frequently, you end up waiting for many roundtrips and the UI gets painfully slow. Some app developers regularly test with remote X over high latency and/or low bandwidth links, and some don't, and it's pretty easy to tell which is which. Some apps are painful even on a LAN, lots of roundtrips add up. If there was appetite to do the work, one could imagine an extension to push client-side rendered window images across in a compressed format, but xorg developers have mostly moved on. There's nx and other external compressors, but there's a missed opportunity, IMHO. Maybe waypipe will fill this void eventually?
- lotharcable 4y ago
  X11 is hopeless. It was a turd 30 years ago. It still is a turd. If it was a simple as "make your toolkit asynchronous" then it would of been done a long time ago. Take Xterm, for example. I did benchmarks over remote systems long ago. When it came to performance over the network it was absolutely trounced by Gnome-Terminal. And Gnome-terminal was a lot slower then then it is now. The reason was because Gnome optimized text output on scrolling text that minimized the latency impact. And it still sucked. There was a reason that it never saw widespread use in the enterprise outside of very nitch sysadmin users on pretty much local area networks. Were as Windows has been used to support thousands of users in a single environment with almost entirely remote applications for a very very long time now. For most users and most applications there is no difference in functionality between remote and local applications. Were as X11 will never be able to accomplish that unless the computer is sitting in the room next to you. Nomachine and similar tech can speed it up, but that isn't really X11 is it?
  - brokenkebab2 4y ago
    >Were as Windows has been used to support It's turning things upside down. Windows has been used in remote because it became dominant, not vice versa. It won in enterprise segment before e.g. even remote support, not to mention remote apps became widespread. And Win's success wasn't that much related to its technical excellence as most of admins from 90s would say
saurik 4y ago
X allows me to run a program on one computer and see it appear on a local desktop, not access a remote desktop from random machines. The former is simply not a use case I am interested in, as I can pretty much always run the graphical program locally instead; in contrast, the latter is something I have found to be extremely useful in numerous situations and even on a near-daily basis back when my life was organized differently... and X simply does not do that, which is why people use solutions like Xvnc (which runs a local X server on the remote machine and then provides you VNC protocol access to its framebuffer).
- tgflynn 4y ago
  I'm not sure what you mean. X can certainly run a full remote desktop, or at least it could, I'm not sure how well it works with current versions of KDE and Gnome. If you mean connect remotely to a desktop that someone else is using on another machine, yes that is indeed a different use case.
  - saurik 4y ago
    I mean the latter, as I maintain the former isn't useful. The people who want to remote desktop into their Windows computer generally aren't asking about this feature so they can simply get fresh access to a remote computer as that's generally not how remote desktop is configured: it is so they can leave all of their programs running on the remote computer and get remote access to it.
    - dixie_land 4y ago
      how is the former not useful? At end of the day there's some app you're running on that RDP session right? X simply allows you to run that app remotely and display it locally. Eg, my kvm (virtualization) host runs RHEL and no desktop environment, but I can easily run virt-manager using X forwarding over SSH when I'm creating a new VM and a GUI is easily than writing a domain XML In face I've forwarded virt-manager to Linux, macOS (XQuartz) and Windows (WSL w/ X server)
      - 4y ago
anonymousiam 4y ago
Things have regressed a lot since then. IMHO this should be part of the normal regression testing on things like Chrome, Firefox, and Thunderbird. As things are now, at least on my system, Chrome doesn't run remotely at all, Firefox does, but lags unbearably (and sometimes crashes) at startup, and Thunderbird lags moderately at startup. (All of this on a 1000Base-T LAN.)
KingOfCoders 4y ago
We we're playing XPilot on X termials on a VAX 25 years ago with no problem (though local university network). I would agree the problem had been solved, but no progress to internet scale. 99.99% of dev effort went into an endless stream of window managers.
kaba0 4y ago
It’s not neglect, we just don’t put 3 lines to the screen by CPU rendering anymore. With the advent of GPU, resolution, complexity of a scene all increased several times, making the problem essentially a completely different one than back in the XMotif days.
sliken 4y ago
I built labs using NCD and HP xterminals. The world was a different place and today people have different expectations. In the xterminal era they often came with minimal ram, I think it was 2MB, with options for 4 or 8MB. Mono, greyscale, or 8 bit color were common, with only the highest end terminals (often more than the entry level workstations) offering 24 bit color. Gradients were rare, usually stipples where used. It wasn't uncommon for palettes per window causing flashing when moving to a new window (because they had a different 256 colors). There were recommendations for particular 256 color palettes for compatible with other tabs/windows. These days 24 bit color icons, buttons, live video, multiple animated ads per window, heavy use offscreen memory for scrolling and the like would kill X based terminals. Sadly things moved so quickly that when the X based terminals were new, people where quite excited to use them. However over the 5 years we used them they got noticeably less usable each year. We ended up replacing them with some diskless linux boxes that could run a 24 bit color window manager and browser locally (fast scrolling and window moving) and ran heavy graphical apps remotely over X11, things like Mathematica, Maple, and Matlab. The lab were suddenly much more in demand, and people hugely preferred them over the Mac and Window based labs students had access to. It was a nice mix of offloading servers (by running X11, window manager, and browsers locally) and offloading clients (by running memory intensive software on the server). People seemed to love the low latency keyboard, scrolling, and browsing. Waiting even a few seconds for Mathematica to churn through a notebook of forumulas and rendering was much easier with a responsive desktop. The diskless linux boxes were easy to admin, reliable, and quiet. Basically browsing is hugely more data intensive than the era of X based terminals, even just scrolling animated windows is tough. Things like a full screen video at 4k was not even under consideration. At the same time people's expectations on performance, latency, and visual richness have increased to the point where X based terminals no longer make sense. Even fast 64 core servers with fast 8 core clients networked over switched GigE gives remote X11 a VERY poor experience these days. Try remote firefox over X11 sometime, it's painful.

znpy 4y ago

Yes it was but the thing is that the problem to solve then got harder. Think about video streaming, 3d acceleration, sound input and output. Then whereas you previously had only a handful of vendors to coerce into agreement, now you have a multitude of individuals that are going to complain for every change.

kllrnohj 4y ago

> probably due to neglect Kinda yes kinda no? Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. So everyone draws stuff on their own, since it's far more flexible and faster. Same is true on windows. RDP is streaming video far more often than it steams drawing commands. You could maybe build something that streams GPU commands, though. Use something like VirtIO-GPU + GFXSTREAM ( https://www.phoronix.com/news/VirtIO-Context-Type https://www.phoronix.com/news/VirtIO-Context-Type ) to stream to an entirely different computer instead of just to the VM host?

PaulDavisThe1st 4y ago
> Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits. The two things that have changed are the underlying GPU technology, which has shifted towards abstractions and APIs mostly targetting gaming and video, and desktop level UI stuff, which is expected to include compositing these days. However, it's not as if the other remote desktop systems have really changed much to reflect these developments either.
- kllrnohj 4y ago
  > This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits. This is really fundamentally wrong. Nobody has been updating X commands for modern effects (eg, blurs, advanced blend modes, etc..). Heck you can't even do round-rect clipping. You have to generate a clip mask pixmap instead. At which point I might as well just generate the final pixmap and forget about X anything. Especially since xlib doesn't even do anti aliasing. Like come the fuck on, it's friggin useless. Can't even handle text adequately! There's a reason Wayland dumped it all entirely. If it had been maintained and updated sure maybe. But it wasn't. It's a drawing library straight out of the 90s, absolute abandonware
  - PaulDavisThe1st 4y ago
    Well, on the one hand, you're right. But on the other hand, X is still being used to do all that stuff (not necessarily using the body of its drawing command set). So even if X's drawing commands themselves are less relevant than they once were, X itself is still entirely capable of presenting GUIs with blurs, anti-aliased text etc. etc.
    - kllrnohj 4y ago
      Well sure but it's just compositing pixmaps from somewhere else. It's just a bad compositor at this point
renox 4y ago
> so everyone draws stuff on their own, since it's far more flexible and faster Faster for which usage? Locally yes, but not remotely where it's worse.. In the beginning Unix desktops were optimised for LAN, and in the process of being optimised for standalone PCs to the dismay off those who access their Linux desktop remotely..
- kllrnohj 4y ago
  > Faster for which usage? Locally yes, but not remotely where it's worse.. How do you know it's actually worse for remote? I can render my entire UI on the GPU & route that straight into a video encoder incredibly quickly. Faster than XLib can draw in the first place. Now there's the bandwidth question there yeah. The video stream takes X Mbps, and the Xlib stream takes Y Mbps. Unless you've measured it recently, you don't actually know if X or Y is smaller. You can make a guess that xlibs is smaller, sure. After all it's vector, right? Except it isn't, not really. Text is all pixmaps. Images are all pixmaps. Path clipping is all pixmaps. Are you compressing all those pixmaps before sending? If so, to what? And is that faster than your GPUs h264 encoder? Almost certainly not. Is it smaller? Also probably not really. And I don't know about you, but I got way more bandwidth than I have latency for my Internet connection. So whether or not X or Y is smaller doesn't actually matter to me. What matters is which gives me less end to end latency, which all but certainly is the video encoder & decoder path, which are incredibly well optimized and hardware accelerated.
  - yjftsjthsd-h 4y ago
    > How do you know it's actually worse for remote? Because I've tried `ssh -X` and in my experience it sucks for any "modern" program (that I've used; I suppose there's bias in my sample).
jcelerier 4y ago
"everyone" is just not true, Qt apps can still send X11 draw commands
- tinus_hn 4y ago
  You can easily draw any desktop with X11 draw commands. They’ll just be Blit Blit Blit Blit Blit Blit Blit The x11 commands allow you to draw lines, ugly patterns, ugly fonts and blit pixmaps. All of them except blitting pixmaps are basically not useful for a modern desktop.
  - jcelerier 4y ago
    This is literally false for Qt. Here's the code: https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/xcb/nativepainting/qpaintengine_x11.cpp#L943 https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/... Here's e.g. dolphin rendered with it here over ssh: https://imgur.com/bLnop55 https://imgur.com/bLnop55 > All of them except blitting pixmaps are basically not useful for a modern desktop. that's ridiculous. Most software is basically a succession of drawLines / drawRect calls with the occasional pixmap.
    - kllrnohj 4y ago
      How much of that dolphin UI is hitting X drawing commands, which appears from your source link to be the simple case only, and how many are rendered to pixmaps and only composited by X? All of the text, for example, is rendered by QT and sent as pixmaps. The drawTextItem path doesn't ever attempt to use XDrawText
      - jcelerier 4y ago
        What simple case ? Every call to drawRect/drawLine that I can see at a glance will end up inside X functions - e.g. calls to QPaintEngine::drawRects will just end up in the function below. And that's the huge majority of the UI. Anyways, what matters to me is that I can resize the window without any lag and compression - it immediately becomes much more laggy and redraw-artefact-y if I disable X11 painting when I access my remote machines so it's pretty obvious when things are using it

II2II 4y ago

Is it a case of people not being interested in the functionality, or a case of the functionality being so poor that people don't want to use it. I remember using X to run applications from half way across North America about 20 years ago. To be specific, I remember using it to do image editing in Gimp. Performance was great. Heck, I even used it over dial-up connections to my university. For some X applications performance was fine, though I was clearly using it for less demanding software. Of course, expectations have changed. Microsoft has acknowledged this by continuing to improve upon Remote Desktop. I love and use the feature, even though I cannot stand Windows. While I use a couple of X applications over the network, for the most part I don't even bother. It's finicky to get working. Even when the fiddly bits are set up properly, there is no guarantee the software will work.

PaulDavisThe1st 4y ago
> It's finicky to get working. ssh -Y remote-host ... % x-application-name What's finicky?
- deleted 4y ago
  [deleted]
- II2II 4y ago
  I can't remember the details, just that I had to setup access control and environment variables.
  - PaulDavisThe1st 4y ago
    That's precisely what ssh -Y or ssh -X do for you.
noAnswer 4y ago
Are you sure you remember it correct? I specificity remember tests we did over ISDN (64kbit/s). Opening KMail (X forwarded over SSH) and rendering changes took several 10s of seconds. There is a reason NoMachine and X2Go got invented.

toast0 4y ago

> probably due to neglect since it's a kind of functionality that not many people seem to be interested in these days X11 is at its heart an asyncrhonous distributed systems protocol (quite similar to Erlang Dist) that happens to output to the screen as a side effect, but a lot of libraries and toolkits (including xlib) provide synchronous abstractions on top. When applications use synchronous abstractions frequently, you end up waiting for many roundtrips and the UI gets painfully slow. Some app developers regularly test with remote X over high latency and/or low bandwidth links, and some don't, and it's pretty easy to tell which is which. Some apps are painful even on a LAN, lots of roundtrips add up. If there was appetite to do the work, one could imagine an extension to push client-side rendered window images across in a compressed format, but xorg developers have mostly moved on. There's nx and other external compressors, but there's a missed opportunity, IMHO. Maybe waypipe will fill this void eventually?

lotharcable 4y ago
X11 is hopeless. It was a turd 30 years ago. It still is a turd. If it was a simple as "make your toolkit asynchronous" then it would of been done a long time ago. Take Xterm, for example. I did benchmarks over remote systems long ago. When it came to performance over the network it was absolutely trounced by Gnome-Terminal. And Gnome-terminal was a lot slower then then it is now. The reason was because Gnome optimized text output on scrolling text that minimized the latency impact. And it still sucked. There was a reason that it never saw widespread use in the enterprise outside of very nitch sysadmin users on pretty much local area networks. Were as Windows has been used to support thousands of users in a single environment with almost entirely remote applications for a very very long time now. For most users and most applications there is no difference in functionality between remote and local applications. Were as X11 will never be able to accomplish that unless the computer is sitting in the room next to you. Nomachine and similar tech can speed it up, but that isn't really X11 is it?
- brokenkebab2 4y ago
  >Were as Windows has been used to support It's turning things upside down. Windows has been used in remote because it became dominant, not vice versa. It won in enterprise segment before e.g. even remote support, not to mention remote apps became widespread. And Win's success wasn't that much related to its technical excellence as most of admins from 90s would say

saurik 4y ago

X allows me to run a program on one computer and see it appear on a local desktop, not access a remote desktop from random machines. The former is simply not a use case I am interested in, as I can pretty much always run the graphical program locally instead; in contrast, the latter is something I have found to be extremely useful in numerous situations and even on a near-daily basis back when my life was organized differently... and X simply does not do that, which is why people use solutions like Xvnc (which runs a local X server on the remote machine and then provides you VNC protocol access to its framebuffer).

tgflynn 4y ago
I'm not sure what you mean. X can certainly run a full remote desktop, or at least it could, I'm not sure how well it works with current versions of KDE and Gnome. If you mean connect remotely to a desktop that someone else is using on another machine, yes that is indeed a different use case.
- saurik 4y ago
  I mean the latter, as I maintain the former isn't useful. The people who want to remote desktop into their Windows computer generally aren't asking about this feature so they can simply get fresh access to a remote computer as that's generally not how remote desktop is configured: it is so they can leave all of their programs running on the remote computer and get remote access to it.
  - dixie_land 4y ago
    how is the former not useful? At end of the day there's some app you're running on that RDP session right? X simply allows you to run that app remotely and display it locally. Eg, my kvm (virtualization) host runs RHEL and no desktop environment, but I can easily run virt-manager using X forwarding over SSH when I'm creating a new VM and a GUI is easily than writing a domain XML In face I've forwarded virt-manager to Linux, macOS (XQuartz) and Windows (WSL w/ X server)
    - 4y ago

anonymousiam 4y ago

Things have regressed a lot since then. IMHO this should be part of the normal regression testing on things like Chrome, Firefox, and Thunderbird. As things are now, at least on my system, Chrome doesn't run remotely at all, Firefox does, but lags unbearably (and sometimes crashes) at startup, and Thunderbird lags moderately at startup. (All of this on a 1000Base-T LAN.)

KingOfCoders 4y ago

We we're playing XPilot on X termials on a VAX 25 years ago with no problem (though local university network). I would agree the problem had been solved, but no progress to internet scale. 99.99% of dev effort went into an endless stream of window managers.

kaba0 4y ago

It’s not neglect, we just don’t put 3 lines to the screen by CPU rendering anymore. With the advent of GPU, resolution, complexity of a scene all increased several times, making the problem essentially a completely different one than back in the XMotif days.

sliken 4y ago

I built labs using NCD and HP xterminals. The world was a different place and today people have different expectations. In the xterminal era they often came with minimal ram, I think it was 2MB, with options for 4 or 8MB. Mono, greyscale, or 8 bit color were common, with only the highest end terminals (often more than the entry level workstations) offering 24 bit color. Gradients were rare, usually stipples where used. It wasn't uncommon for palettes per window causing flashing when moving to a new window (because they had a different 256 colors). There were recommendations for particular 256 color palettes for compatible with other tabs/windows. These days 24 bit color icons, buttons, live video, multiple animated ads per window, heavy use offscreen memory for scrolling and the like would kill X based terminals. Sadly things moved so quickly that when the X based terminals were new, people where quite excited to use them. However over the 5 years we used them they got noticeably less usable each year. We ended up replacing them with some diskless linux boxes that could run a 24 bit color window manager and browser locally (fast scrolling and window moving) and ran heavy graphical apps remotely over X11, things like Mathematica, Maple, and Matlab. The lab were suddenly much more in demand, and people hugely preferred them over the Mac and Window based labs students had access to. It was a nice mix of offloading servers (by running X11, window manager, and browsers locally) and offloading clients (by running memory intensive software on the server). People seemed to love the low latency keyboard, scrolling, and browsing. Waiting even a few seconds for Mathematica to churn through a notebook of forumulas and rendering was much easier with a responsive desktop. The diskless linux boxes were easy to admin, reliable, and quiet. Basically browsing is hugely more data intensive than the era of X based terminals, even just scrolling animated windows is tough. Things like a full screen video at 4k was not even under consideration. At the same time people's expectations on performance, latency, and visual richness have increased to the point where X based terminals no longer make sense. Even fast 64 core servers with fast 8 core clients networked over switched GigE gives remote X11 a VERY poor experience these days. Try remote firefox over X11 sometime, it's painful.