4 ms·

Maintenance mode != dead [1] This just means that development of _new_ features and research should take place on Wayland where it belongs. From what I've read

by tomxor 7y ago

Maintenance mode != dead [1] This just means that development of _new_ features and research should take place on Wayland where it belongs. From what I've read X has been a long evolution into a hodepodge of historical but effectively dead interfaces with newer ones crammed along side... it doesn't make sense to continue the tradition of cramming more features into X, but that doesn't stop people developing new things on top of it while Wayland matures. [1] https://en.wikipedia.org/wiki/Maintenance_mode https://en.wikipedia.org/wiki/Maintenance_mode

chaosfox 7y ago
yes, and they specifically said: We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum which gives us a 10 year-ish time frame of support from RH.
DonHopkins 7y ago
It's sad that maintenance mode != dead. They should have put X-Windows out of its misery decades ago! What's actually sad is that its replacement, Wayland, didn't learn any of the lessons of NeWS (or what we now call AJAX) and Emacs. They could at least throw a JavaScript engine in as an afterthought. But it's WAY too late to actually design the entire thing AROUND an extension language, like NeWS and Emacs and TCL/Tk, which is how it should have been in the first place. https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: + used PostScript code instead of JavaScript for programming. + used PostScript graphics instead of DHTML and CSS for rendering. + used PostScript data instead of XML and JSON for data representation. Designing a system around an extension language from day one is a WHOLE lot better than nailing an extension language onto the side of something that was designed without one (and thus suffers from Greenspun's tenth rule). This isn't rocket surgery, people. https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule >Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... >If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles — but you’d be able to shift gears with your car stereo. Useful feature, that. - Marus J. Ranum, Digital Equipment Corporation
- Jasper_ 7y ago
  That's the Wikipedia summary, but the details matter heavily. NeWS was developed in the time before "personal computing", for workstations where all software was trusted. The threat model was "what threat?" It also baked into assumptions about the graphics model and where the expensive parts are. It has the same fatal flaw as the X11 graphics model: that rendering will be far slower than I/O traffic, so socket bandwidth will never be the bottleneck. Embedded programmability has ended up being a security disaster. It was perhaps ahead of its time, but we understand its flaws and principles now.
  - DonHopkins 7y ago
    You seem to be misunderstanding that I'm advocating that X-Windows be replaced by NeWS in 2019. That's not at all what I'm saying. I guess you're one of those people who always uses the noscript extension in your browser, and drives to the bank, pays for a parking place, and waits in line instead of using online banking. Have you ever used Google Maps? Are you arguing that everybody should turn off JavaScript and use online maps that you scroll by clicking and waiting for another page to load? You must really hate it when WebGL shaders download code into your GPU!
    - Jasper_ 7y ago
      Considering I'm the author of one of the more technically advanced WebGL apps out there ( https://noclip.website/ https://noclip.website/), I understand the power of the web as an application delivery platform. NeWS-style programmability does not have the same advantages. I cannot host a NeWS application in one place and send a single link to let others run it. The NeWS architecture put graphics rendering responsibility on the server with Display PostScript (also a mistake X11 made), and the scripting was so you could design a button in one process and instance it in another. It was a workaround for the lack of shared libraries, not a way of moving computation to a data center (the reason you use AJAX).
      - DonHopkins 7y ago
kevin_b_er 7y ago
You mean _parity_ features? SSHing into a server and launching a small GUI tool is still dead. It was killed by Wayland intentionally and willfully as a fundamental design idea. In fact, the feature of doing that is considered "not part of wayland" by Wayland designers. The root problem is that wayland replaced half of x.org and left the rest for someone else to figure out.
- jhasse 7y ago
  > SSHing into a server and launching a small GUI tool is still dead. They are working on native support for that via PipeWire. For the time being you can still do that with Xwayland.
  - erik_seaberg 7y ago
    PipeWire is video streaming, not remote rendering. They're assuming a rack of GPUs in the datacenter and a virtual circuit dedicated to me, but in reality I have a congested link and one GPU attached to my display.
    - vardump 7y ago
      The question is, which is more data. Rendered result or the data to do the rendering. If the rendered result is lighter, then a video stream makes perfect sense. If sending the data over to render is lighter, there's still one more issue: that GPUs are still not interchangeable, and the server hosting the application needs to have the necessary information about all the possible GPUs, their quirks and limitations. And you might still get inconsistent results at various clients. My personal guess is that the data to render is a lot more than data the required to do video streaming. So much depends on doing CPU rendering directly to textures. Although more and more is moving to GPU, so...
    - Dylan16807 7y ago
      X forwarding is pretty awful over congested links and high-latency links in my experience. And from what I've seen if a program has even a medium-low level of graphical intensity it's not going to interact well with X forwarding. So anything that previously worked, should still work without a GPU.

by tomxor 7y ago

chaosfox 7y ago

yes, and they specifically said: We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum which gives us a 10 year-ish time frame of support from RH.

DonHopkins 7y ago

It's sad that maintenance mode != dead. They should have put X-Windows out of its misery decades ago! What's actually sad is that its replacement, Wayland, didn't learn any of the lessons of NeWS (or what we now call AJAX) and Emacs. They could at least throw a JavaScript engine in as an afterthought. But it's WAY too late to actually design the entire thing AROUND an extension language, like NeWS and Emacs and TCL/Tk, which is how it should have been in the first place. https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: + used PostScript code instead of JavaScript for programming. + used PostScript graphics instead of DHTML and CSS for rendering. + used PostScript data instead of XML and JSON for data representation. Designing a system around an extension language from day one is a WHOLE lot better than nailing an extension language onto the side of something that was designed without one (and thus suffers from Greenspun's tenth rule). This isn't rocket surgery, people. https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule >Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... >If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles — but you’d be able to shift gears with your car stereo. Useful feature, that. - Marus J. Ranum, Digital Equipment Corporation

Jasper_ 7y ago
That's the Wikipedia summary, but the details matter heavily. NeWS was developed in the time before "personal computing", for workstations where all software was trusted. The threat model was "what threat?" It also baked into assumptions about the graphics model and where the expensive parts are. It has the same fatal flaw as the X11 graphics model: that rendering will be far slower than I/O traffic, so socket bandwidth will never be the bottleneck. Embedded programmability has ended up being a security disaster. It was perhaps ahead of its time, but we understand its flaws and principles now.
- DonHopkins 7y ago
  You seem to be misunderstanding that I'm advocating that X-Windows be replaced by NeWS in 2019. That's not at all what I'm saying. I guess you're one of those people who always uses the noscript extension in your browser, and drives to the bank, pays for a parking place, and waits in line instead of using online banking. Have you ever used Google Maps? Are you arguing that everybody should turn off JavaScript and use online maps that you scroll by clicking and waiting for another page to load? You must really hate it when WebGL shaders download code into your GPU!
  - Jasper_ 7y ago
    Considering I'm the author of one of the more technically advanced WebGL apps out there ( https://noclip.website/ https://noclip.website/), I understand the power of the web as an application delivery platform. NeWS-style programmability does not have the same advantages. I cannot host a NeWS application in one place and send a single link to let others run it. The NeWS architecture put graphics rendering responsibility on the server with Display PostScript (also a mistake X11 made), and the scripting was so you could design a button in one process and instance it in another. It was a workaround for the lack of shared libraries, not a way of moving computation to a data center (the reason you use AJAX).
    - DonHopkins 7y ago

kevin_b_er 7y ago

You mean _parity_ features? SSHing into a server and launching a small GUI tool is still dead. It was killed by Wayland intentionally and willfully as a fundamental design idea. In fact, the feature of doing that is considered "not part of wayland" by Wayland designers. The root problem is that wayland replaced half of x.org and left the rest for someone else to figure out.

jhasse 7y ago
> SSHing into a server and launching a small GUI tool is still dead. They are working on native support for that via PipeWire. For the time being you can still do that with Xwayland.
- erik_seaberg 7y ago
  PipeWire is video streaming, not remote rendering. They're assuming a rack of GPUs in the datacenter and a virtual circuit dedicated to me, but in reality I have a congested link and one GPU attached to my display.
  - vardump 7y ago
    The question is, which is more data. Rendered result or the data to do the rendering. If the rendered result is lighter, then a video stream makes perfect sense. If sending the data over to render is lighter, there's still one more issue: that GPUs are still not interchangeable, and the server hosting the application needs to have the necessary information about all the possible GPUs, their quirks and limitations. And you might still get inconsistent results at various clients. My personal guess is that the data to render is a lot more than data the required to do video streaming. So much depends on doing CPU rendering directly to textures. Although more and more is moving to GPU, so...
  - Dylan16807 7y ago
    X forwarding is pretty awful over congested links and high-latency links in my experience. And from what I've seen if a program has even a medium-low level of graphical intensity it's not going to interact well with X forwarding. So anything that previously worked, should still work without a GPU.