6 ms·

X is kind of amazing. Once, just for fun, I had an SGI do window management, another one serve up fonts, a linux box serving apps via NFS, and yet another head

X is kind of amazing. Once, just for fun, I had an SGI do window management, another one serve up fonts, a linux box serving apps via NFS, and yet another headless SGI running a shared app displayed on yet another Linux machines X window server session. It was surreal. Launch that app, and all those machines contributed to the interaction of it. Plus, it made that instance of RH Linux look like an SGI. 4dwm has a distinct look and feel. For the most part, running over a 100T network, one could not tell all that was happening. (Was a high end CAD app.) Later, I did run that same app remotely, using its Windows NT build and the Exceed X server for Win NT. Cool.

kevin_thibedeau 7y ago
I like being able to run a Linux desktop in a VM on windows and "extend" to another monitor with VM X apps rendering to a Cygwin Xorg instance. Wayland can't do that.
- cycloptic 7y ago
  There is no reason wayland couldn't do that, other than that your compositor doesn't support the concept of virtual screens. I can't say that this is a very high-priority feature for any compositors at the moment.
  - ddingus 7y ago
    And that is why X is kind of amazing. They thought it all through. Today, it is a game of which pieces make the most sense, and whether multi user graphical computing should be a thing. We know it can. X did all that. Should it?
    - cycloptic 7y ago
      As far as Wayland goes, that is up to the developers and users of those compositors. The protocol itself supports the concept of multiple seats. I can't speak for all the original X developers but TFA seems to suggest that they didn't think it all through.
      - ddingus 7y ago
        When X is matched, then we can discuss whether that is true. Currently, it's not. That does not make current efforts bad. I think they are quite nice. They just do not yet actualize the vision X did and does today. Whether that is wanted / needed is also an open discussion at this time.
        cycloptic 7y ago
        It won't be matched unless someone sees enough of a need to make it happen. Wayland the protocol doesn't have an explicit goal of doing everything that X did. The design is different. As far as I can tell, the original vision of X was to unify all the proprietary Unix vendors with a standard windowing protocol. The network capabilities happened because they wanted to support dumb terminals connected to mainframes. Most of those proprietary Unix vendors are now gone. Currently it's not clear to me what role X is supposed to have, if any.
        ddingus 7y ago
        The role is multi user graphical computing. I made comments elsewhere in thread about that. We may find or choose for that to not be a thing. Ok, fine. The X window people did make that a thing and the end result is powerful and flexible. None of that makes efforts like Wayland bad. They aren't. But they, by your own definition, are a subset of what X is too. They aren't thinking it through, by design. That is OK.
        cycloptic 7y ago
        Wayland (the protocol) supports the necessary bits and it's up to the compositors if they want to go the extra mile to support everything. My own personal take is that most compositors won't because X does not represent multi user graphical computing in the way that most people use it today. That role is fulfilled by web applications.
        pjmlp 7y ago
        Commercial UNIX vendors, Xerox, TI, Genera, were already doing that before X was created.
- ddingus 7y ago
  Yup. In my humble opinion, the people who built X really did think through what multi user graphical computing meant. I like X. Took me a while to understand it, but once I did, I used it hard and appreciated what it allowed me to do. Doing stuff like dual or multi head computers. Multi users each with their own keyboard and mouse can happen with X. And if one needs another user, doing it via network just works. X is a powerful thing.
- the8472 7y ago
  The compositor would have to talk to the virtual GPU driver to allocate additional surfaces on the host and make them available to the guest. The next best alternative currently is looking glass[0]. Linux host with GPU1, Windows guest with GPU2 via pass-through and then copy the framebuffer from the guest to the host. [0] https://looking-glass.hostfission.com/ https://looking-glass.hostfission.com/
- Gnurou 7y ago
  > I like being able to run a Linux desktop in a VM on windows and "extend" to another monitor with VM X apps rendering to a Cygwin Xorg instance. Wayland can't do that. This should be possible with virtio-wayland: https://alyssa.is/using-virtio-wl/ https://alyssa.is/using-virtio-wl/ It's pretty new and not used outside of Chrome OS (to run Linux apps) at the moment though.
technofiend 7y ago
DEC or HP (I no longer remember which) wrote a cool demo that had a fish swim across as many displays as you gave it. It properly rendered the fish split across display edges. With walls of displays being so common now it doesn't sound like much but at the time it was a pretty slick demo of X window and its network capability.
- ddingus 7y ago
  That's cool
- LargoLasskhyfv 7y ago
  Sounds like http://dmx.sourceforge.net/ http://dmx.sourceforge.net/ which is part of X.Org since release https://www.x.org/wiki/Releases/6.8/ https://www.x.org/wiki/Releases/6.8/ from 2004.
  - technofiend 7y ago
    No this predated all that. I saw the demo in 1991 or 1992; you had a simple flat file with a list of displays to use or could supply it on the command line. The program itself had to do all the heavy lifting to determine how much of each fish to put on each display.
donio 7y ago
That chapter was dumb even when it came out. X is awesome and it's amazing how well it has stood the test of time. I am not looking forward to the day when I won't be able to do half the things I do today with my EXWM setup because we needed to have "every frame perfect".
- ddingus 7y ago
  It is like UNIX. The people who created X thought multi user graphical computing all the way through. We may decide that should not be a thing. I think we will struggle, some time will pass, and then it will be a thing, meaning X will just get reinvented.
  - netsharc 7y ago
    Probably using a node.js background, websocket, and DOM-manipulating JavaScript.. or WebGL for performance..
    - bitwize 7y ago
      It will only take up a couple of GiB of RAM to display hello, world.
      - unlinked_dll 7y ago
        More like 200MB but who cares? RAM is cheap(er than CPU cycles and developer salaries)
        bitwize 7y ago
        Well, I projected forward a few years and imagined how it would be when software "evolves" and becomes more "modern".
    - pjmlp 7y ago
      That is NeWS being reinvented, with JavaScript taking the place of Postscript, not X.
glangdale 7y ago
Agreed. And I may be showing my age, but I learned C and C++ on singles MIPS boxes (R3000 processors) shared between 20 users, all on X terminals. The thought of sharing 1 32-bit processor running at 25Mhz between 20 people running any kind of graphical environment it pretty wild by today's standards.
- ddingus 7y ago
  I am just gonna ramble for a minute. Plz either indulge or ignore. I miss this stuff! Thanks. I would have loved to profile that little system. It's crazy how lean those older systems really were. A 30Mhz R4K could play MP3 files streamed via NFS. (90 percent CPU utilization, not headless, with local desktop logged in and active) I had one, at that clock useless by the time I got it, doing just that, because why not? After reading your comment, I realize I had a machine just playing a compressed audio file with the resources needed to serve 20 of you a useful computing environment! What kind of network were you on? Was it even ethernet? 10T? My first multi-user experience was horrible! It was on a 386/25, running Xenix and it had capacity for 16 users via either 19200 or 9600 baud SERIAL and VT100 terminals... I had 12 users at peak on that one, and most of them ran multi-user WordPerfect and some MRP thing, Symix, I think. I got the job because I read all the manuals. First sysadmin post and it was a pig. Learned a ton though! Enough to realize I could have a lot of fun on the better UNIXes, and scored a position working with SGI computers. (in that timeframe those computers with all the spiffy software so well engineered were like computing from the future, so much fun) Another time, while doing sysadmin on an SGI Irix multi-cpu Origin system serving some 30 users doing high end cad, I did some data logging. That system had 16GB Ram, 4 R12K CPU's with super fat caches, dual homed 1000T ethernet, BTW. I forget the clock. Probably 400Mhz I logged user activity every few seconds for roughly a week. This was an effort to see whether overall system speed was impacting productivity. I had a few users grumble during a peak time, so... Learned a few things: The system itself could perform near max capability when there were 4 concurrent user CAD demands. OS overhead was a few percent tops, in almost all circumstances. This was not in of itself any kind of issue. Irix ran pretty damn lean. Once in a blue moon, the system would page, but the Irix file caches are gold. This never really was an issue either. Maybe for a few minutes at a time during a serious push tops. A few times per week, usually on a Friday, they would max it out, and more than 4 concurrent, high demand sessions would be present. Deffo slowdown. Among the users, the average full compute demand was roughly 2 minutes. Some instances of this were longer for power users working on more substantial models. 5 to 10 minutes. These were sporadic, during the day. The reason was simple, and it was a model recompute. Happens as users roll up all their changes. Interestingly, light duty users, doing detail drawings, or minor model updates, sustaining engineering type stuff, they used the system heavy, perhaps 60 percent of their workday, but rarely hit peak single core compute for more than a few seconds at a time. Was hard to even see these. They did not really do big recomputes, but they did do the occasional big drawing render, and those were as bad as the power users. But not even daily. Most users hit the system both harder and less frequently. 20 to 30 percent of their day, but did post up regular ~2minute single core max compute demands. These people were working on sub systems, and would often copy one, modify, update, check it in, done, next. The power users hit the ~5 to 10 minute peak compute and used the system half the day. They were working at the entire product level. Big demands on RAM, CPU, Network. Multiple times daily. What I did was put local compute resources in front of the power users and restructure the network to give them a quieter, higher throughput subnet. There were a few of these users. They did became network bound, as the data transfer was significant compared to everyone else running on the main server, with high throughput disks. (15K RPM Cheetah drives) This impacted their get going times, but they only did that occasionally. Once things got cached locally, non issue overall. They adjusted how they work and marginalized it. The biggest saving was honestly to just keep it logged in, screen locked, etc... The rest of the users reported a significant speed up after these things were done. Now, here's the thing! A second data logging actually did show the power users improve. And they responded by burying those boxes, opening up a second session on the main one to continue. LOL, fine. It was good enough before, so I said nothing. They were power users and working at the product level and gains there paid off nicely in terms of total project capacity per year. No worries. There to help, blah, blah. But I did chuckle about them very rapidly figuring out how things worked. (They used the excellent virtual desktop feature in the 4dwm window manager common to SGI computers. One click and they were viewing their local session, one more click and they were viewing their remote one, next.) But everyone else demonstrated no real change! The data just was not there to support a big gain, and it totally was not there after the power users did their thing by running two sessions anyway. So, what was it? Turned out to be network. When I put the local compute where it needed to be, we moved some switches and had inadvertently improved load balancing at the physical layer. Some users, prior to this, were basically blocking others. Latency went down for everyone, and average throughput went up, and that proved to be the single most gratifying improvement for them, and it was just faster interactive response. No effective change in actual compute / time unit available, nor demanded from them. The parallels today are obvious. Get that page response time down. Effective throughput, what users can get done may bump up a little, but the vast majority won't do it. But, their feel, perception will ramp right up to the positive. This is true even when it comes at the expense of other things maybe being slower, taking longer. Just get them feedback NOW, and they will feel better about it all anyway.

kevin_thibedeau 7y ago

I like being able to run a Linux desktop in a VM on windows and "extend" to another monitor with VM X apps rendering to a Cygwin Xorg instance. Wayland can't do that.

cycloptic 7y ago
There is no reason wayland couldn't do that, other than that your compositor doesn't support the concept of virtual screens. I can't say that this is a very high-priority feature for any compositors at the moment.
- ddingus 7y ago
  And that is why X is kind of amazing. They thought it all through. Today, it is a game of which pieces make the most sense, and whether multi user graphical computing should be a thing. We know it can. X did all that. Should it?
  - cycloptic 7y ago
    As far as Wayland goes, that is up to the developers and users of those compositors. The protocol itself supports the concept of multiple seats. I can't speak for all the original X developers but TFA seems to suggest that they didn't think it all through.
    - ddingus 7y ago
      When X is matched, then we can discuss whether that is true. Currently, it's not. That does not make current efforts bad. I think they are quite nice. They just do not yet actualize the vision X did and does today. Whether that is wanted / needed is also an open discussion at this time.
      - cycloptic 7y ago
        It won't be matched unless someone sees enough of a need to make it happen. Wayland the protocol doesn't have an explicit goal of doing everything that X did. The design is different. As far as I can tell, the original vision of X was to unify all the proprietary Unix vendors with a standard windowing protocol. The network capabilities happened because they wanted to support dumb terminals connected to mainframes. Most of those proprietary Unix vendors are now gone. Currently it's not clear to me what role X is supposed to have, if any.
        ddingus 7y ago
        The role is multi user graphical computing. I made comments elsewhere in thread about that. We may find or choose for that to not be a thing. Ok, fine. The X window people did make that a thing and the end result is powerful and flexible. None of that makes efforts like Wayland bad. They aren't. But they, by your own definition, are a subset of what X is too. They aren't thinking it through, by design. That is OK.
        cycloptic 7y ago
        Wayland (the protocol) supports the necessary bits and it's up to the compositors if they want to go the extra mile to support everything. My own personal take is that most compositors won't because X does not represent multi user graphical computing in the way that most people use it today. That role is fulfilled by web applications.
        pjmlp 7y ago
        Commercial UNIX vendors, Xerox, TI, Genera, were already doing that before X was created.
ddingus 7y ago
Yup. In my humble opinion, the people who built X really did think through what multi user graphical computing meant. I like X. Took me a while to understand it, but once I did, I used it hard and appreciated what it allowed me to do. Doing stuff like dual or multi head computers. Multi users each with their own keyboard and mouse can happen with X. And if one needs another user, doing it via network just works. X is a powerful thing.
the8472 7y ago
The compositor would have to talk to the virtual GPU driver to allocate additional surfaces on the host and make them available to the guest. The next best alternative currently is looking glass[0]. Linux host with GPU1, Windows guest with GPU2 via pass-through and then copy the framebuffer from the guest to the host. [0] https://looking-glass.hostfission.com/ https://looking-glass.hostfission.com/
Gnurou 7y ago
> I like being able to run a Linux desktop in a VM on windows and "extend" to another monitor with VM X apps rendering to a Cygwin Xorg instance. Wayland can't do that. This should be possible with virtio-wayland: https://alyssa.is/using-virtio-wl/ https://alyssa.is/using-virtio-wl/ It's pretty new and not used outside of Chrome OS (to run Linux apps) at the moment though.

technofiend 7y ago

DEC or HP (I no longer remember which) wrote a cool demo that had a fish swim across as many displays as you gave it. It properly rendered the fish split across display edges. With walls of displays being so common now it doesn't sound like much but at the time it was a pretty slick demo of X window and its network capability.

ddingus 7y ago
That's cool
LargoLasskhyfv 7y ago
Sounds like http://dmx.sourceforge.net/ http://dmx.sourceforge.net/ which is part of X.Org since release https://www.x.org/wiki/Releases/6.8/ https://www.x.org/wiki/Releases/6.8/ from 2004.
- technofiend 7y ago
  No this predated all that. I saw the demo in 1991 or 1992; you had a simple flat file with a list of displays to use or could supply it on the command line. The program itself had to do all the heavy lifting to determine how much of each fish to put on each display.

donio 7y ago

That chapter was dumb even when it came out. X is awesome and it's amazing how well it has stood the test of time. I am not looking forward to the day when I won't be able to do half the things I do today with my EXWM setup because we needed to have "every frame perfect".

ddingus 7y ago
It is like UNIX. The people who created X thought multi user graphical computing all the way through. We may decide that should not be a thing. I think we will struggle, some time will pass, and then it will be a thing, meaning X will just get reinvented.
- netsharc 7y ago
  Probably using a node.js background, websocket, and DOM-manipulating JavaScript.. or WebGL for performance..
  - bitwize 7y ago
    It will only take up a couple of GiB of RAM to display hello, world.
    - unlinked_dll 7y ago
      More like 200MB but who cares? RAM is cheap(er than CPU cycles and developer salaries)
      - bitwize 7y ago
        Well, I projected forward a few years and imagined how it would be when software "evolves" and becomes more "modern".
  - pjmlp 7y ago
    That is NeWS being reinvented, with JavaScript taking the place of Postscript, not X.

glangdale 7y ago

Agreed. And I may be showing my age, but I learned C and C++ on singles MIPS boxes (R3000 processors) shared between 20 users, all on X terminals. The thought of sharing 1 32-bit processor running at 25Mhz between 20 people running any kind of graphical environment it pretty wild by today's standards.

ddingus 7y ago
I am just gonna ramble for a minute. Plz either indulge or ignore. I miss this stuff! Thanks. I would have loved to profile that little system. It's crazy how lean those older systems really were. A 30Mhz R4K could play MP3 files streamed via NFS. (90 percent CPU utilization, not headless, with local desktop logged in and active) I had one, at that clock useless by the time I got it, doing just that, because why not? After reading your comment, I realize I had a machine just playing a compressed audio file with the resources needed to serve 20 of you a useful computing environment! What kind of network were you on? Was it even ethernet? 10T? My first multi-user experience was horrible! It was on a 386/25, running Xenix and it had capacity for 16 users via either 19200 or 9600 baud SERIAL and VT100 terminals... I had 12 users at peak on that one, and most of them ran multi-user WordPerfect and some MRP thing, Symix, I think. I got the job because I read all the manuals. First sysadmin post and it was a pig. Learned a ton though! Enough to realize I could have a lot of fun on the better UNIXes, and scored a position working with SGI computers. (in that timeframe those computers with all the spiffy software so well engineered were like computing from the future, so much fun) Another time, while doing sysadmin on an SGI Irix multi-cpu Origin system serving some 30 users doing high end cad, I did some data logging. That system had 16GB Ram, 4 R12K CPU's with super fat caches, dual homed 1000T ethernet, BTW. I forget the clock. Probably 400Mhz I logged user activity every few seconds for roughly a week. This was an effort to see whether overall system speed was impacting productivity. I had a few users grumble during a peak time, so... Learned a few things: The system itself could perform near max capability when there were 4 concurrent user CAD demands. OS overhead was a few percent tops, in almost all circumstances. This was not in of itself any kind of issue. Irix ran pretty damn lean. Once in a blue moon, the system would page, but the Irix file caches are gold. This never really was an issue either. Maybe for a few minutes at a time during a serious push tops. A few times per week, usually on a Friday, they would max it out, and more than 4 concurrent, high demand sessions would be present. Deffo slowdown. Among the users, the average full compute demand was roughly 2 minutes. Some instances of this were longer for power users working on more substantial models. 5 to 10 minutes. These were sporadic, during the day. The reason was simple, and it was a model recompute. Happens as users roll up all their changes. Interestingly, light duty users, doing detail drawings, or minor model updates, sustaining engineering type stuff, they used the system heavy, perhaps 60 percent of their workday, but rarely hit peak single core compute for more than a few seconds at a time. Was hard to even see these. They did not really do big recomputes, but they did do the occasional big drawing render, and those were as bad as the power users. But not even daily. Most users hit the system both harder and less frequently. 20 to 30 percent of their day, but did post up regular ~2minute single core max compute demands. These people were working on sub systems, and would often copy one, modify, update, check it in, done, next. The power users hit the ~5 to 10 minute peak compute and used the system half the day. They were working at the entire product level. Big demands on RAM, CPU, Network. Multiple times daily. What I did was put local compute resources in front of the power users and restructure the network to give them a quieter, higher throughput subnet. There were a few of these users. They did became network bound, as the data transfer was significant compared to everyone else running on the main server, with high throughput disks. (15K RPM Cheetah drives) This impacted their get going times, but they only did that occasionally. Once things got cached locally, non issue overall. They adjusted how they work and marginalized it. The biggest saving was honestly to just keep it logged in, screen locked, etc... The rest of the users reported a significant speed up after these things were done. Now, here's the thing! A second data logging actually did show the power users improve. And they responded by burying those boxes, opening up a second session on the main one to continue. LOL, fine. It was good enough before, so I said nothing. They were power users and working at the product level and gains there paid off nicely in terms of total project capacity per year. No worries. There to help, blah, blah. But I did chuckle about them very rapidly figuring out how things worked. (They used the excellent virtual desktop feature in the 4dwm window manager common to SGI computers. One click and they were viewing their local session, one more click and they were viewing their remote one, next.) But everyone else demonstrated no real change! The data just was not there to support a big gain, and it totally was not there after the power users did their thing by running two sessions anyway. So, what was it? Turned out to be network. When I put the local compute where it needed to be, we moved some switches and had inadvertently improved load balancing at the physical layer. Some users, prior to this, were basically blocking others. Latency went down for everyone, and average throughput went up, and that proved to be the single most gratifying improvement for them, and it was just faster interactive response. No effective change in actual compute / time unit available, nor demanded from them. The parallels today are obvious. Get that page response time down. Effective throughput, what users can get done may bump up a little, but the vast majority won't do it. But, their feel, perception will ramp right up to the positive. This is true even when it comes at the expense of other things maybe being slower, taking longer. Just get them feedback NOW, and they will feel better about it all anyway.