7 ms·

For someone not familiar with this world, what is X Server and xfree86? What problem does it solve?

billsmithaustin 6y ago
See https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System.
waynecochran 6y ago
It provides an implementation for the X Window System (aka X11) https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System It has a long a storied history. The concept of running an app remotely and use a local display server is probably the thing that sets X11 apart from the rest of the pack. This is still really useful in my humble opinion -- I can run X11 apps (e.g. xv) on a headless EC2 server running Linux in the cloud and have the UI/display on my Mac (using Xquartz). This story runs in parallel with the history of Unix itself.
- https443 6y ago
  Thanks!
- Wowfunhappy 6y ago
  The fact that there is an implementation of X on Mac speaks to the power of this system, IMO. However, regarding remote setups, is X forwarding significantly superior to using something like VNC? I've never done a side-by-side myself, but most of what I've read indicates that VNC is usually faster. As a semi-experiment, a few months ago I decided to try running Firefox in a Linux VM, and render it in XQuartz on my Mac host. The experience was not pleasant, to say the least. And that's what I'd think to be the best-case-scenario for latency. Hard for me to imagine using it over WAN.
  - freeone3000 6y ago
    Depends on the era of apps. If you're doing mostly bitmaps (that is, Qt4+, GTK2+, anything that draws its own UI, anything with HTML incl all electron, anything using GL, anything using composition) then VNC will work better, as it transfers better bitmaps. Working with Xlib, GTK1, or Qt3-era or earlier apps, X will perform astoundingly better. Test with xemacs next time, and you should see your results inverted.
  - mprovost 6y ago
    There was a lot of work done to make X11 work better over low bandwidth/high latency links. [0] But in the end you could get most of the benefits just by forwarding your X session over SSH with compression enabled. Although X11 is old enough that compression would have used too much CPU back when it was developed. The more interesting comparison between X forwarding and VNC is that X is really only displaying a remote application locally, not an entire screen or desktop. (Unless you use xnest to run X inside X which is pretty cool.) I used to have a FreeBSD workstation with a browser window running on a Linux server and a bunch of terminal windows spun up on different Sun servers, and you couldn't tell the difference between your local and remote windows. Remote windows are first class citizens in X11. [0] https://en.wikipedia.org/wiki/Low_Bandwidth_X https://en.wikipedia.org/wiki/Low_Bandwidth_X
    - StillBored 6y ago
      A better comparison with X is the RDP protocol, which too is an API level protocol (its basically forwarding large parts of the windows GDI interface). OTOH, the big strength of RDP is the async stream requests. This gives it a much lower apparent latency than X, but it can also do the VNC thing and render/compress parts of the UI on the remote machine.
throwaways885 6y ago
It started a long time ago, back in the days of mainframes and thin clients. Mainframe boxes would run the sever side part of "X Server" while clients (ambiguous term in this context, I'll admit) would send commands (e.g. keyboard strokes) and receive graphics back. XFree86 is a free software implementation of the X Window System. The whole server/client thing is a bit outdated now, since almost nobody uses actual thin clients anymore. X forwarding is useful, but it's not a mainstream way to do your computing.
- pjmlp 6y ago
  We do use them, it is called browser nowadays.
  - Koshkin 6y ago
    I don’t know, web browsers today are almost too powerful to be called “virtual programmable HTTP terminals”...
  - GekkePrutser 6y ago
    I like this analogy... It's very true, and has a lot of local rendering which at the time of X terminals was a bit of a pipe dream. They could just locally render some things like fonts. Sun also tried to get into this game early with the JavaStations. But they were ridiculously slow, so painful to use. In fact they kind of ruined Java for me. I was learning it at the time, and we got a JavaStation on loan from somewhere. Working on it just established this "Java = slow" feeling in my head and really put me off so much I went to do other things. Of course this wasn't really deserved, and Java has gone on to become powerful (though I still consider its poor intra-version compatibility an issue). But I've never been able to quite shake that feeling.
- https443 6y ago
  Thanks!
- bitwize 6y ago
  Not quite. The X server ran on the client only. The "mainframe" (usually a Unix server) had client programs that would connect to your X server, send it display commands, and receive pointer and keyboard events. The client-server relationship was reversed from the usual way, because the server was sitting in front of the user. The end-user computer was providing a service -- access to the user -- to the big machine in the server room.
linguae 6y ago
X11 is a window system. An X client is an application that uses the X protocol (e.g., Firefox, GIMP, LibreOffice) while an X server is an implementation of the X protocol that handles the rendering. Note that an X server and an X client don't have to run on the same machine; if I log into a remote server and execute LibreOffice, LibreOffice is still the X client and my machine's X implementation is still the X server, despite the fact that LibreOffice is running remotely. XFree86 is a specific X server implementation, though it has been superseded by X.org sometime around 2004 due to a license change from the MIT license to the 4-clause BSD license, which is incompatible with the GPL. X.org is by far the most dominant X server implementation in the free open source software community, but it is not the only implementation; off the top of my head there were proprietary X server implementations for SunOS and NeXT.
- asveikau 6y ago
  > though it has been superseded by X.org sometime around 2004 due to a license change from the MIT license to the 4-clause BSD license, My understanding is that the scene for the fork had already been set by the time of the relatively late license change. I seem to recall reading at the time that the XFree86 core team was unhappy that a sole contributor was attempting to modernize the system by introducing extensions, without building consensus around them to their satisfaction. So the license change was meant to prevent forks from merging in further work on XFree86. Of course the fork was adding functionality everybody wanted. So the fork survived and upstream languished.
  - linguae 6y ago
    Based on my understanding, the license change was "the straw that broke the camel's back." There were already murmurs of a fork due to disagreements among XFree86 developers, but the license change was the final push that led to distributions choosing not to adopt XFree86 4.4, the first version with the new license.
  - dialamac 6y ago
    > I seem to recall reading at the time that the XFree86 core team was unhappy that a sole contributor was attempting to modernize the system by introducing extensions, without building consensus around them to their satisfaction. This is a kind of odd retelling/interpretation of events, considering the “rogue” contributor version is the only one that lived and XFree86 is history.

See https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System.

It provides an implementation for the X Window System (aka X11) https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System It has a long a storied history. The concept of running an app remotely and use a local display server is probably the thing that sets X11 apart from the rest of the pack. This is still really useful in my humble opinion -- I can run X11 apps (e.g. xv) on a headless EC2 server running Linux in the cloud and have the UI/display on my Mac (using Xquartz). This story runs in parallel with the history of Unix itself.

https443 6y ago
Thanks!
Wowfunhappy 6y ago
The fact that there is an implementation of X on Mac speaks to the power of this system, IMO. However, regarding remote setups, is X forwarding significantly superior to using something like VNC? I've never done a side-by-side myself, but most of what I've read indicates that VNC is usually faster. As a semi-experiment, a few months ago I decided to try running Firefox in a Linux VM, and render it in XQuartz on my Mac host. The experience was not pleasant, to say the least. And that's what I'd think to be the best-case-scenario for latency. Hard for me to imagine using it over WAN.
- freeone3000 6y ago
  Depends on the era of apps. If you're doing mostly bitmaps (that is, Qt4+, GTK2+, anything that draws its own UI, anything with HTML incl all electron, anything using GL, anything using composition) then VNC will work better, as it transfers better bitmaps. Working with Xlib, GTK1, or Qt3-era or earlier apps, X will perform astoundingly better. Test with xemacs next time, and you should see your results inverted.
- mprovost 6y ago
  There was a lot of work done to make X11 work better over low bandwidth/high latency links. [0] But in the end you could get most of the benefits just by forwarding your X session over SSH with compression enabled. Although X11 is old enough that compression would have used too much CPU back when it was developed. The more interesting comparison between X forwarding and VNC is that X is really only displaying a remote application locally, not an entire screen or desktop. (Unless you use xnest to run X inside X which is pretty cool.) I used to have a FreeBSD workstation with a browser window running on a Linux server and a bunch of terminal windows spun up on different Sun servers, and you couldn't tell the difference between your local and remote windows. Remote windows are first class citizens in X11. [0] https://en.wikipedia.org/wiki/Low_Bandwidth_X https://en.wikipedia.org/wiki/Low_Bandwidth_X
  - StillBored 6y ago
    A better comparison with X is the RDP protocol, which too is an API level protocol (its basically forwarding large parts of the windows GDI interface). OTOH, the big strength of RDP is the async stream requests. This gives it a much lower apparent latency than X, but it can also do the VNC thing and render/compress parts of the UI on the remote machine.

throwaways885 6y ago

It started a long time ago, back in the days of mainframes and thin clients. Mainframe boxes would run the sever side part of "X Server" while clients (ambiguous term in this context, I'll admit) would send commands (e.g. keyboard strokes) and receive graphics back. XFree86 is a free software implementation of the X Window System. The whole server/client thing is a bit outdated now, since almost nobody uses actual thin clients anymore. X forwarding is useful, but it's not a mainstream way to do your computing.

pjmlp 6y ago
We do use them, it is called browser nowadays.
- Koshkin 6y ago
  I don’t know, web browsers today are almost too powerful to be called “virtual programmable HTTP terminals”...
- GekkePrutser 6y ago
  I like this analogy... It's very true, and has a lot of local rendering which at the time of X terminals was a bit of a pipe dream. They could just locally render some things like fonts. Sun also tried to get into this game early with the JavaStations. But they were ridiculously slow, so painful to use. In fact they kind of ruined Java for me. I was learning it at the time, and we got a JavaStation on loan from somewhere. Working on it just established this "Java = slow" feeling in my head and really put me off so much I went to do other things. Of course this wasn't really deserved, and Java has gone on to become powerful (though I still consider its poor intra-version compatibility an issue). But I've never been able to quite shake that feeling.
https443 6y ago
Thanks!
bitwize 6y ago
Not quite. The X server ran on the client only. The "mainframe" (usually a Unix server) had client programs that would connect to your X server, send it display commands, and receive pointer and keyboard events. The client-server relationship was reversed from the usual way, because the server was sitting in front of the user. The end-user computer was providing a service -- access to the user -- to the big machine in the server room.

linguae 6y ago

X11 is a window system. An X client is an application that uses the X protocol (e.g., Firefox, GIMP, LibreOffice) while an X server is an implementation of the X protocol that handles the rendering. Note that an X server and an X client don't have to run on the same machine; if I log into a remote server and execute LibreOffice, LibreOffice is still the X client and my machine's X implementation is still the X server, despite the fact that LibreOffice is running remotely. XFree86 is a specific X server implementation, though it has been superseded by X.org sometime around 2004 due to a license change from the MIT license to the 4-clause BSD license, which is incompatible with the GPL. X.org is by far the most dominant X server implementation in the free open source software community, but it is not the only implementation; off the top of my head there were proprietary X server implementations for SunOS and NeXT.

asveikau 6y ago
> though it has been superseded by X.org sometime around 2004 due to a license change from the MIT license to the 4-clause BSD license, My understanding is that the scene for the fork had already been set by the time of the relatively late license change. I seem to recall reading at the time that the XFree86 core team was unhappy that a sole contributor was attempting to modernize the system by introducing extensions, without building consensus around them to their satisfaction. So the license change was meant to prevent forks from merging in further work on XFree86. Of course the fork was adding functionality everybody wanted. So the fork survived and upstream languished.
- linguae 6y ago
  Based on my understanding, the license change was "the straw that broke the camel's back." There were already murmurs of a fork due to disagreements among XFree86 developers, but the license change was the final push that led to distributions choosing not to adopt XFree86 4.4, the first version with the new license.
- dialamac 6y ago
  > I seem to recall reading at the time that the XFree86 core team was unhappy that a sole contributor was attempting to modernize the system by introducing extensions, without building consensus around them to their satisfaction. This is a kind of odd retelling/interpretation of events, considering the “rogue” contributor version is the only one that lived and XFree86 is history.