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: 5, Insightful) by Bot on Saturday February 10 2018, @08:53AM (24 children)

    by Bot (3902) on Saturday February 10 2018, @08:53AM (#635944) Journal

    A. X network transparency is a failure
    B. study about X network transparency is a failure

    personally, given that remote X apps (over LAN but also over servers on this side of the ocean) are very practical for some purposes, and for the others there is x11vnc which shares the current session, and given that sdl games are fluid enough, I can't really say A. Which leaves, um...

    --
    Account abandoned.
    Starting Score:    1  point
    Moderation   +3  
       Insightful=3, Informative=1, Overrated=1, Total=5
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 4, Informative) by Anonymous Coward on Saturday February 10 2018, @09:35AM (4 children)

    by Anonymous Coward on Saturday February 10 2018, @09:35AM (#635950)

    Correct. I've used X11 over network or tunneled over SSH a lot in the last ~20 odd years. Even GLX worked just fine for what it was doing (though that's not something I've tried recently).

    • (Score: 2) by bzipitidoo on Saturday February 10 2018, @04:21PM (2 children)

      by bzipitidoo (4388) on Saturday February 10 2018, @04:21PM (#636034) 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, every utility in sbin really. Do not need X for system administration, remote or local. As for X terminals, computers are so cheap now I don't see the point of bothering with a dumb terminal, not when you can smarten it up by employing a $5 Raspberry Pi with the monitor, keyboard, and mouse, each of which likely costs more than the computer. Having a kind of KVM could be a reason, but that too is suspect. It's hard for one person to effectively utilize several GUIs. Maybe for visualizing proteins as you're folding them, or for playing several characters at the same time in the same MMORPG or FPS, but that latter is just easier with several complete computers.

      I used X tunneled through ssh only once, to remotely run Wireshark (just before the name change from Ethereal), to diagnose some network issues with a VoIP app on a remote machine, and that only because I didn't bother checking into whether Ethereal had a text based interface (seems like it should), while all the tools for X tunneling were already set up. Needed packet sniffing at both ends to figure out what was going on.

      • (Score: 3, Interesting) by sjames on Saturday February 10 2018, @04:36PM

        by sjames (2882) on Saturday February 10 2018, @04:36PM (#636041) Journal

        I prefer text based administration, but there are too many corner cases such as installers that don't offer text as an option (for some stupid reason), browser apps that don't work in text AND insist on connecting to a randomized port so you can't open an ssh tunnel in advance, etc that it's better to just use X over an ssh tunnel.

        In my home setup, I have a desktop machine that's nice and quiet and I have a 2U server that sounds a bit like a shop-vac when it gets busy. So I put it in another room and use X over the network for CPU intensive work that wants a graphical display.

      • (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.
    • (Score: 0) by Anonymous Coward on Wednesday February 14 2018, @12:51AM

      by Anonymous Coward on Wednesday February 14 2018, @12:51AM (#637379)

      GLX seems to be the pain point they use when claiming X is not network transparent.

      But what they do not state is that GLX used to be network transparent, but that was discarded in trying to eek out those last few frames pr second and finally entice game companies to support Linux.

      Didn't happen, because in doing so they just demonstrated that they can't be assed to maintain API compatiblity across versions like Microsoft can (old directx games work without a patch on Windows 10 more often than not).

      And now we have the whole compositor DE eyecandy boondongle going on, that is feeding directly into Wayland hype.

      This under the pretext that X11 can't produce frames without tearing, except that every damn person that complains about that is running Nvidia proprietary drivers with vsync disabled!

      In effect what is going on is JWZ's CADT on an epic scale. And the day Linus hands over the reins of the kernel to GKH, is the day that CADT reach the kernel. And that day is the day Linux dies a slow, painful death.

  • (Score: 5, Interesting) by Anonymous Coward on Saturday February 10 2018, @09:54AM (4 children)

    by Anonymous Coward on Saturday February 10 2018, @09:54AM (#635952)

    Maybe 'ported' apps using a shitty toolkit are of questionable utility over the network, but I have plenty of X apps that run perfectly well over the network and transparently. Hell, NASA and SGI both released a whole pile of network monitoring tools a decade ago whose primary purpose was providing real time feedback from remote computers to client windows on centralized X servers. But bear in mind most of these apps used native X widgets and not simply bitmapped crap under gtk or qt.

    Really the solution to X's shortcomings today isn't a system like wayland, but rather a return of the DPS (Display PostScript) servers, now that technology has improved to the point where the gpu could transparently and in real time decode the display postscript content, scaling it to match screen resolution and DPI, and providing the wsywig feedback needed for the widgets to interact with the cursor(s) or touch display events without issues due to trying to calculate fast enough to work out what pixel and most-foreground widget intersect (which if I am remembering correctly was the major crux of some of that UI design methodology.)

    Today however it is almost ludicrious to in-app bitmapping going on which just results in excessive memory usage in the app which could instead be pushed to the gpu, and even there limited to time spent rendering to the display, or an indirect buffer being displayed or otherwise output.

    • (Score: 5, Informative) by Unixnut on Saturday February 10 2018, @12:00PM (1 child)

      by Unixnut (5779) on Saturday February 10 2018, @12:00PM (#635974)

      Yeah I was going to post the same thing, but you did a good enough job.

      Been using X for more than a decade, even remotely across the internet. I found that it works great. Using SSH and X forwarding, the fact I can run a program on a server across the world and have it show up seamlessly integrated into my desktop is really something.

      Over a high speed link (or LAN) it is transparent to the point that I don't even know if the program I am interacting with is running on my machine or not, which is the holy grail of remote display protocols. It even integrates the clipboards, so I can copy/paste and drag and drop seamlessly.

      Even full X terminal sessions work great, and for a long time (back before "Silent PCs" were a thing) I would shove my big, multidisk, noisy workstation up in the attic, where I can't hear it, and use a thin terminal at my desk via a 100mbit network, and it worked great.

      As this was in the days of OSS (https://en.wikipedia.org/wiki/Open_Sound_System) and we didn't have pulseAudio, I used Esound (https://en.wikipedia.org/wiki/Enlightened_Sound_Daemon) to transport the audio over the network to my thin client).

      You could even watch videos over X, and while not as good as local, it was much better than I expected it would be if I am honest. I wouldn't use it as a home cinema system, but for casual viewing it was fine.

      The only thing I've would say would be nice is:

      - Ability to resume full remote Xsessions when disconnected. Normally when you disconnect your session is shut down, and you have to relogin. Xrdp/Sesman kind of handles this nowadays, but it isn't fully developed/integrated last time I checked. Losing everything because of a network glitch is a PITA.

      - Ability to forward USB (so for example, I plug a USB key into the terminal, its data can be accessed on the remote session). This would probably fit better under its own server/client daemon rather than be shoved into X. Maybe some more generic sharing protocol. You can kinda script this together with NFS, remote mounts, etc... but it could do with refinement and usability improvements.

      I suspect the people who go on about X being a failure are those who value "eyecandy" over functionality. If you are rending full bitmaps in your graphics toolkit in order to do all kinds of fancy effects and animations (to the point where you need 3D graphics acceleration just for your window manager), I can believe that remote X would be a pile of shit.

      At best, it will work about as well as VNC (which was designed to do nothing but shove bitmaps across) at which point they will say the protocol is a bloated mess because 90% of the features are not used. At worst it will be dog slow, high latency, and generally a poor experience compared to VNC, so they will say X is a failure.

      X is a shit protocol to transport bitmaps across, there are actual protocols that work that way (such as VNC), which is probably why to them VNC makes sense. That doesn't mean that X is a failure, any more than complaining a hammer is a failure because you can't spread butter on your toast properly with it.

      Different tools for different tasks.

      • (Score: 0) by Anonymous Coward on Saturday February 10 2018, @03:04PM

        by Anonymous Coward on Saturday February 10 2018, @03:04PM (#636012)

        Xpra does some of what you're asking for (persistence, usb forwarding, sound etc.)

        It's a bit of a hack, and it's not really X forwarding, but it feels like X forwarding.

    • (Score: 2, Insightful) by Burz on Saturday February 10 2018, @04:23PM (1 child)

      by Burz (6156) on Saturday February 10 2018, @04:23PM (#636035)

      Please... spare us the primitivism.

      Every time I see anecdotes from Unix techies griping about "bitmapped crap" and calling for a return to the old days (yeah, the 1980s) I'm reminded of the excellent developments in _usable_ network transparency that Apple and Microsoft did in the early 2000s. On the heels of that work came applications allowing ordinary users to do things like _share_ windows and desktops in a conference mode.

      There is nothing X-related that approaches that level of functionality (the "first-class environment" OP article refers to) save for the work done on the NX protocol, which none of the commenters here even appear to remember. NX was the only over-Internet extension of X that made nearly as good as Apple and MS network transparency in terms of speed and features.

      So the FOSS GUI field ignored a whole generation of graphics development because it already had a mostly-unusable (to regular people) version of network transparency from the 1980s. They said "we already have that" and remained ignorant. And they still plod onward, wondering why people don't prefer Linux desktops where they can do their conferencing in a nice Windows 10 virtual machine.

      • (Score: 0) by Anonymous Coward on Saturday February 10 2018, @04:38PM

        by Anonymous Coward on Saturday February 10 2018, @04:38PM (#636043)

        please, spare us the dumbing down of everything, we are already getting to idiocracy levels and bs like this just doesn't help

  • (Score: 5, Informative) by tonyPick on Saturday February 10 2018, @10:12AM (5 children)

    by tonyPick (1237) on Saturday February 10 2018, @10:12AM (#635957) Homepage Journal

    As we're throwing in anecdotes... "ssh -X" (or "ssh -Y") works fantastically well for most all the apps I try, (with the notable exception of QtCreator. Damn you QtCreator.).

    Hell, I'm not even 100% certain which machine_this_ Firefox session is running on. Over a LAN it's seamless, and I've run over a crappy old modem then onto a machine across the Atlantic, and had key X apps (terminals, editors) viable enough to work with on the remote side directly. It sure as hell beat waking finding somebody from the UK office awake at 2 in the morning to run the things locally.

    IMO: In a world of containers, virtual machines, and distributed devices across multiple physical hardware items on links of varying capacity then remote X, with minimal network traffic, is becoming more relevant and more important, not less. The most common reason for not using it I've ever heard is "I didn't know it could do that".

    • (Score: 4, Informative) by VLM on Saturday February 10 2018, @03:26PM (2 children)

      by VLM (445) Subscriber Badge on Saturday February 10 2018, @03:26PM (#636019)

      As we're throwing in anecdotes... "ssh -X" (or "ssh -Y") works fantastically well for most all the apps I try

      In the spirit of anecdotes this following apps work beautifully:

      mythtv-setup (the crazy GUI is the only way to set up mythtv)

      emacs (frigging beautiful)

      octave's GUI IDE thing (although honestly I mostly have finger muscle memory now to type octave --no-win)

      GNU-R's GUI IDE

      The following apps that I use which don't work via X network transparency:

      (blank space here)

      Admittedly I've been spending a possibly unhealthy amount of time using rdesktop and VNC into entire hosted vmware cluster environments but I do occasionally forward simple apps using X and its always worked pretty well.

      • (Score: 5, Interesting) by Nerdfest on Saturday February 10 2018, @04:54PM

        by Nerdfest (80) on Saturday February 10 2018, @04:54PM (#636051)

        Yeah, I'm with you. I'm not crazy about the speed sometimes, but almost everything I've ever needed to run over tunnelled X has worked. There have been a couple with problems, but not inconvenient enough that I even remember what they were. I'd like to see a better solution eventually (not sure if Wayland is it), but not something like the the architectural horror that is systemd. It really does seem there's a systematic attack on Linux going on these days.

      • (Score: 2) by digitalaudiorock on Saturday February 10 2018, @07:16PM

        by digitalaudiorock (688) on Saturday February 10 2018, @07:16PM (#636105) Journal

        In the spirit of anecdotes this following apps work beautifully:

        mythtv-setup (the crazy GUI is the only way to set up mythtv)

        Yup...I do this all the time. This shit has just plain worked for it's intended purposes just about forever, yet suddenly now, in the days of gigabit LANs and 200 Mbps Internet, the Wayland fanboys want us to believe that it's too slow to be viable or some such crap? Talk about FUD. There seem to be a lot of know-it-alls destroying open source software these days. I'll no sooner use Wayland than systemd.

    • (Score: 1) by Burz on Saturday February 10 2018, @04:41PM (1 child)

      by Burz (6156) on Saturday February 10 2018, @04:41PM (#636044)

      Most people don't care about using a Firefox instance sitting on a remote computer. Many of them _do_ want an efficient way to _share_ their own windows and sessions via Internet conferencing. X doesn't allow for this, and VNC is too primitive/inefficient. Windows and OS X proprietary protocols have this ability, which is an important (though seldom-cited) reason why FOSS systems can't make it on the desktop (as in: you can't even give this stuff away for free). We have paid dearly for clinging to 1980s technology.

      • (Score: 1) by Burz on Saturday February 10 2018, @05:12PM

        by Burz (6156) on Saturday February 10 2018, @05:12PM (#636057)

        I'd also like to point out the irony of wanting to use one remote-display protocol to render another, newer one (HTML); meaning this is a corner-case at best.

  • (Score: 5, Interesting) by TheRaven on Saturday February 10 2018, @12:21PM (6 children)

    by TheRaven (270) on Saturday February 10 2018, @12:21PM (#635976) Journal

    The problem with X's network transparency was that they put it at the wrong layer and so it sucked for a long time. The X protocol is entirely asynchronous, so you can batch up a bunch of commands and hide latency, but XLib exposed synchronous APIs, so you ended up with one network round trip for each line you drew. This got worse when applications moved the rendering to local buffers and used the display server to just draw them on the screen (which you needed for things like antialiased text and for sane font handling). Then things got a bit better with the trio of damage, render, and composite extensions, where you could render an image locally, transfer it to the server, have the server composite it, and only update parts that had changed.

    In contrast, Sun's NeWS system, which competed with X early on, put the network at the controller layer in the MVC model. The display server had code sent to it, not just data, so your display server knew, for example, that something was a button and to animate it when it was clicked, while simultaneously sending a button-clicked event across the network to the application.

    These days, the web browser is increasingly becoming a modern version of NeWS. You can send it textures, fonts, and code for drawing UIs and with WebSocket you can get low-latency asynchronous events. If I were designing a new display server, I'd think about using a NeWS-like model with WebAssembly replacing PostScript as the language for server-side interpreted code, but still expose a PostScript drawing model and OpenGL, so that it could be implemented both as a native display server and in a web browser with the canvas tag and WebGL.

    --
    sudo mod me up
    • (Score: 1, Insightful) by Anonymous Coward on Saturday February 10 2018, @12:39PM (3 children)

      by Anonymous Coward on Saturday February 10 2018, @12:39PM (#635979)

      If I were designing a new display server, I'd think about using a NeWS-like model with WebAssembly replacing PostScript

      Good thing you are not, then. As if we need MORE attack surface for virii and trojans to exploit.

      • (Score: 2, Insightful) by TheRaven on Saturday February 10 2018, @06:12PM (2 children)

        by TheRaven (270) on Saturday February 10 2018, @06:12PM (#636080) Journal

        Right, because that's a much lower attack surface than X already has, where any code that runs as the current user can intercept all events and can run any arbitrary code on the GPU and can snoop on the contents of all existing windows.

        You basically have two choices: run code on the display server, or accept that remote display is going to suck on any network with nontrivial latency.

        --
        sudo mod me up
        • (Score: 2, Informative) by Anonymous Coward on Saturday February 10 2018, @06:36PM (1 child)

          by Anonymous Coward on Saturday February 10 2018, @06:36PM (#636092)

          https://www.x.org/wiki/Development/Documentation/Security/ [x.org]
          And never assume that if you do not know about something, no one else does.

          • (Score: 2) by TheRaven on Sunday February 11 2018, @10:40AM

            by TheRaven (270) on Sunday February 11 2018, @10:40AM (#636326) Journal
            Nothing in that link contradicts what I said. The authentication mechanisms (including Kerberos) let any process that can read files owned by the user connect. The SECURITY extension has so many caveats that it's effectively nonexistent. Anything that is allowed to use the GLX extension can still run code on your GPU which can snoop on the contents of all other windows.
            --
            sudo mod me up
    • (Score: 0) by Anonymous Coward on Sunday February 11 2018, @05:30AM (1 child)

      by Anonymous Coward on Sunday February 11 2018, @05:30AM (#636273)

      Years ago someone created a new C async binding, XCB, a more direct link to the X Protocol. XLib was partialy reimplemented with it to improve things. https://en.wikipedia.org/wiki/XCB [wikipedia.org]

      But we keep getting huge toolkits that going dumber and dumber, for the great shiny and the mobile experience (yeah, in your desktop or laptop). I remember when Alan Cox discovered GNOME was really slow due to fonts, because the apps where looking for the files (instead of... I don't know, create a new font system in X11, with aliasing and proper compositing, including proper gamma correction... we got fontconfig & freetype, which assume fixed gamma and B&W colors) and doing it over and over. His home machines used NFS, so multiple file requests (for nothing in the end) slowed everything. Also I remember when one app was found recalcing own widget layout thousands of times per second, instead of a more sane 100... after all the user will not see more than the monitor refresh (anything above 200FPS would be stupid).

      • (Score: 2) by TheRaven on Sunday February 11 2018, @10:45AM

        by TheRaven (270) on Sunday February 11 2018, @10:45AM (#636327) Journal

        XCB was a huge improvement. I've written code that used it, and the model is pretty nice. You can fit it into an actor-model programming environment and defer waiting for the acks for a long time. Having XLib implemented on top of XCB simplified the XLib code a lot, but didn't really help anything using XLib, because you're still using a synchronous API on top, so the XLib APIs end up doing an async call and then blocking on the result. I don't know what the status of other toolkits moving to XCB is, but it had the potential for a lot of improvements.

        The problem for X font handling was somewhat inherent in the client-server design. If you want to support fairly dumb X terminals running an X server and nothing else, then you don't want to put font handling there because installing a new font means adding the font to the terminal (which may not even have writeable storage). The XRender extension actually has a pretty sensible way of dealing with fonts. The client renders each glyph into a texture and transfers it to the server, the server can then composite the glyphs into the correct place. This is exactly the same model that Quartz uses on OS X. That said, most things using Cairo don't actually use XRENDER this way, they instead render in software on the client and send the resulting image to the server. At least if they use XDAMAGE they're not sending an entire window contents every time a cursor blinks though...

        --
        sudo mod me up
  • (Score: 3, Insightful) by Whoever on Saturday February 10 2018, @05:11PM

    by Whoever (4524) on Saturday February 10 2018, @05:11PM (#636056) Journal

    Let's not forget that the original plan was that Wayland would NOT have network transparency. It was only the outrage of Linux users that changed it.

    This seems to be a weak justification for that original position, based on the fact that network transparency in X has some limitations.