Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Saturday February 10 2018, @08:12AM   Printer-friendly
from the maybe-Y-will-be-better dept.

Chris Siebenmann over on his personal web page at the University of Toronto writes about X networking. He points out two main shortcomings preventing realization of the original vision of network transparancy. One is network speed and latency. The other is a too narrow scope for X's communication facilities.

X's network transparency was not designed as 'it will run xterm well'; originally it was to be something that should let you run almost everything remotely, providing a full environment. Even apart from the practical issues covered in Daniel Stone's slide presentation [warning for PDF], it's clear that it's been years since X could deliver a real first class environment over the network. You cannot operate with X over the network in the same way that you do locally. Trying to do so is painful and involves many things that either don't work at all or perform so badly that you don't want to use them.

Remote display protocols remain useful, but it's time to admit another way will have to be found. What's the latest word on Wayland or Mir?

Source : X's network transparency has wound up mostly being a failure


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by frojack on Saturday February 10 2018, @07:18PM

    by frojack (1554) on Saturday February 10 2018, @07:18PM (#636107) Journal

    Why? I mean, sure, it can be cool to see an X based app running remotely, but there are a lot of text screen based resources, like, oh, the "screen" utility, and wget and links for some web work, rsync, and bash, and well,

    Why? Because there are some applications where its necessary to have graphical outputs, and the quickest path is X over a sufficiently fast network.

    Rather than rewriting each application to send data over a socket and then write a client to graphically display that shit, (a custom one off job for each application needing remote display) which can take man-years to build, just use the tools at hand. X over the network.

    Its easier to get gigabit ethernet end-to-end (across the campus or across the ocean) than it is to rewrite applications.

    Sure, starting from scratch you can build that data-shipping-to-client into the each new app. Its easy, because there are so many standards to choose from, right? /snort. No matter which you pick it will be wrong.

    (We've done this in my day job, and found we could hang the tcp-stack between the software and the display generation, but that required a client, and it also meant we had to design our own transmission protocol, and we had to encrypt stuff in both directions. But we had the requirement up front, and full control of the data-to-screen stack. We weren't trying to retrofit it into someone's existing steaming pile of agile crap.)

    The real world does not revolve around a collection of command line utilities, and wget and links for "web work". And the real world has to be multi platform.

    --
    No, you are mistaken. I've always had this sig.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2