[adamzegelin]

You can also use Gimp via a RDP or VNC session, which will give much better performance on low-bandwidth connections, since those protocols do damage detection, only sending updates of what's changed, and (lossy) compression.

I'm not an expert, but my understanding is that the whole X11 is network transparent thing worked great when apps used the X11 drawing primitives. These days a significant number of X11 apps just render _everything_ (often including window decorations) "server-side" as bitmaps and then send them over the wire to the client to composite them. Essentially the X11 wire protocol has become a bitmap pipe.

Wayland does the "bitmap pipe" thing more efficiently than X11.

[amelius]

Very much this. Running the X11 protocol over the network is usually not a good idea anymore.

By the way, does anyone know of a VNC-like solution that can use MPEG compression?

Also, VNC could be better if it could increase the quality of parts of the screen once they stop updating. E.g. in TigerVNC setting a low bitrate doesn't improve the quality of text once the text stops changing.

[aidenn0]

Nomachine's server and client are closed-source but work great.

For open-source solution for quickly remoting into an existing display, I use freerdp-shadow-cli which is way more stable than x11vnc and uses the RDP protocol instead.

[RealStickman_]

Nomachine used to be open source. X2Go is the open source continuation of that.

[aidenn0]

I think their current version is unrelated to what is now x2go

[izacus]

XPRA uses H.264, PNG or JPEG compression. Chrome Remote Desktop will use VP9 these days.

[chpatrick]

https://xpra.org/

[msla]

> Running the X11 protocol over the network is usually not a good idea anymore.

It works well, though, and I'm not really interested in hearing that my own experience with it working well is a lie or some trick. Wayland gives up some things, and pretending that those things have no value isn't going to convince those of us who know they do.

Also, those of us who use non-mainstream window managers (such as Window Maker) are not interested in hearing that we should switch to some UI which doesn't support our workflow just because it's more fashionable these days.

There's a debate to be had here, and it needs to be had on the basis of facts, not lies.

[gbin]

TBH This response is way too aggressive for the original comment.

The facts stated are simply that today it is more efficient to encode video for remote graphical sessions because the X11 applications already changed a long long time ago to adapt to the modern world of GPUs and accelerated compositing. BW, latency, efficiency, everything became better because a super computer with thousands of cores can do that and lighten the load on the CPUs.

It doesn't say it doesn't work... It doesn't prevent you neither from running X11 or even booting up a PDP-11 if this is your favorite workflow!

[d110af5ccf]

The problem is that the Wayland fans have a tendency (at least I feel) to significantly misrepresent things in their favor. Statements like "oh that's actually more efficient on Wayland". No, Wayland is incapable of the sorts of optimizations X can do by design. It is only more efficient if the X app is doing things in a specific way that doesn't take advantage of huge parts of the X protocol. Granted, most modern apps do exactly that at this point. That doesn't make such statements any less of a misrepresentation though.

A much more reasonable claim would be that the network transparency afforded by the X protocol adds significant complexity which is no longer utilized by the majority of mainstream apps today. As such there's a reasonable case for dropping all that complexity from the core system and leaving it to peripheral libraries to handle on a case by case basis for the apps that want to make use of it.

And the idea of lossy compression while using an image editing program being a desirable thing (as suggested elsewhere in this comment chain) is laughable. It's already bad enough reading text that's gone through lossy compression. I would never want compression artifacts while manipulating an image.

My impression of Wayland so far is that I like the technicals but absolutely detest the people I encounter pushing it as a solution (it's quite similar to Rust in that regard I suppose). They would probably meet less resistance if they took more care not to misrepresent the overall state of things. I'll leave the link to KDE Wayland "showstoppers" for reference. Certainly that list is far shorter today than it used to be and many (not all) of the items are now solely on KDE's end. Nonetheless, fanboys have been claiming that Wayland is "production ready" the entire time. https://community.kde.org/Plasma/Wayland_Showstoppers

I'll switch to Wayland once it "just works" out of the box in terms of app integration on stable distributions including things like screen capture, fractional scaling factors, color management, all the stuff that works on X.

[cycomanic]

Well the people who are pushing wayland are the same people that are maintaining xorg, so I would argue they know what they are talking about.

I have also not heard of any one who loudly proclaims xorg is much beter and should instead be maintained to step up to actually do that.

[michaelmrose]

Look at this very statement it's completely inaccurate in a trivial fashion that ought not required analysis but here we are.

The people who actually develop x or wayland are a tiny number of people. The people expressing opinions on the internet on tech is 1000x larger. The implications that the proponents are correct in their analysis because they develop it is fatally flawed if for no other reason than the subject is obviously not solely the tiny number of actual devs. Furthermore the arguments even of devs needs to stand on their own feet.

Look at the prior comments where someone complains that random crashes result in the entire session going down.

Who cares what anyone says about the theoretical design decisions regarding manifestly unsuitable tools.

[ongy]

You are saying that as if the part of the X11 protocol that's reasonable to run over the network was the better API that application developers are simply too lazy to use.

While the reality is, that toolkits (and applications) used to use those APIs and were revamped to use the DRI APIs and general bitmap based windowing. The old APIs don't support double buffering, access to GPUs with modern APIs (both opengl[indirect sucks] and Vulkan). They don't provide modern font rendering, or any kind of graphical effect (distortions) that UI people might want to play with.

They would be significantly worse for anything displaying animations and one of the most common client libs (libx11) is serial and thus horribly latency sensitive.

The advantage of VNC isn't lossy compression. Which isn't forced by it either. But it handles networking better with bitmaps. And has improvements like acting as a screen/tmux style connectable session for graphical applications. Both VNC/RDB can also support showing the server's desktop if it has one, not just running other applications than currently open elsewhere.

The only advantage of old style X11 was that it's ubiquitous. But since it hasn't been used in ages since it doesn't work well with modern computers/UI frameworks that advantage is gone. And there's 0 reason to try and reimplement that in a new windowing protocol, when there's objectively better choices out there already. Local optimized windowing is a different beast than network capable.

[customkitchen]

You might also want to note that the fantasy of being able to use the same protocol to drive the local display and also operate over a network, is long dead. It seems like a clever idea but it doesn't actually work. It ceased to be a thing entirely the moment wide area networks became popular. The local and remote cases are two completely different situations that need their own individual attention. Even when developing against X11 protocol you still have to consider this in modern times because the DRI extension is not available over the network.

Compare to a protocol like RDP which is extremely optimized for efficient and secure network operation, but is also way more complicated as a result, and it would be foolish to use it on a local display server.

[ziftface]

It does just work for some workflows. I think that's really what it boils down to. It is production ready for some people, but it's clearly not for you yet. Maybe that will change.

[Amezarak]

Yes, I see this come up again and again. Meanwhile, I use X11 over the network every day with Firefox, GIMP, various custom apps, and a zillion other things. And it works fine, and great, and VNC isn't an option for most of it for me.

[customkitchen]

>and I'm not really interested in hearing that my own experience with it working well is a lie or some trick.

Your own experiences with it aren't a lie, but they're probably based around ignoring the last 20-30 years of advancements, and ignoring many actual statements from the X11 developers saying that it's bad for remoting.

>Wayland gives up some things

Well in the case of X11 fowarding, no it doesn't. That still works.

>Also, those of us who use non-mainstream window managers (such as Window Maker) are not interested in hearing that we should switch to some UI which doesn't support our workflow just because it's more fashionable these days.

By insisting on using these obscure, non-mainstream and under-maintained environments you are setting yourself up for an extraordinary amount of pain for very little benefit. The more time you spend avoiding the issue the harder it gets to figure out how to adapt your workflow to something else. I'm sure you understand that more deeply than anyone else here. So why keep up with the charade? It is not doing you any favors. At some point we have to let bad habits die.

[torginus]

If you're not afraid of big brother, I can recommend Chrome Remote desktop. You just install a server on the shared machine, and you can access your stuff using a regular browser thanks to the wonders of WebRTC.

[j1elo]

I recently had to uninstall Chrome Remote Desktop, because it was breaking my (Ubuntu) system's ability to handle some basic permissions, such as mounting USB disks.

It turns out that CRD is well known for breaking other seemingly random things, such as accessing your printer:

https://askubuntu.com/questions/1196248/automount-when-click...

[baq]

> By the way, does anyone know of a VNC-like solution that can use MPEG compression?

try this: https://xpra.org/

[stuaxo]

Not sure on the exact compression but I'm sure Nomachine/NX must use some video compressing n, I'm even able to watch video over it without it dying.

[aappleby]

Parsec, I think?

[satya71]

I think TurboVNC had some extensions in that direction. But it’s been a while since I looked at it.

[mark254]

> By the way, does anyone know of a VNC-like solution that can use MPEG compression?

You want xpra.

[LtWorf]

but doing ssh -X is scertainly easier than setting up vnc.

[POPOSYS]

X2GO is the way to go!

[cbm-vic-20]

> my understanding is that the whole X11 is network transparent thing worked great when apps used the X11 drawing primitives.

It did. It was awesome to be able to run one of the expensive academic apps from any X terminal on campus. Network security was largely non-existent then, and you could run X apps not just across campus but across the Internet. I remember a really early web page that had a text field (for your host name) and a button that would start a particular app on their side and would display on your local X server. It wasn't very fast.

Anyway, all that died as Athena and Motif began to look dated as newer applications in the mid-90s started using more and more bitmaps.

[Rediscover]

Completely off-topic, and I wish I could DM You without extra spam here, but great handle. Commodore Business Machines... Ever use a PET? Loved those things.

[moomin]

I was around back in the days that X-servers were still very much a thing, and even then many thought they were an expensive and inefficient way of doing things.

However, there were many who genuinely believed that networks would get arbitrarily faster and compute would not. Of course, the opposite happened, but in that alternative universe X’s design would have made sense.

[taeric]

This isn't quite right. Both have gotten arbitrarily faster. That some folks have gigabit fiber is proof of that. Graphics have just outpaced networking. Easily.

[cycomanic]

The problem with X over the network is not bandwidth it is latency. The X11 protocol is very chatty so even very simple things will cause several roundtrips which makes X over the network so painful.

[destructionator]

> The X11 protocol is very chatty so even very simple things will cause several roundtrips which makes X over the network so painful.

This simply isn't true. Some operations require roundtrips, drag and drop comes to mind, but very simple things absolutely don't. Events come one way, draw commands go the other.

[cycomanic]

Well that's not what the xorg website says: https://www.x.org/wiki/Development/Documentation/Performance...

Essentially xlib is latency limited because its a synchronous protocol. Xcb can help if you redesign your applications for it, but we are talking about old applications (motif...)

[destructionator]

You know xcb and xlib are just different client libraries for accessing the exact same wire protocol, right?

Moreover, notice the example they gave there is atom interning, which is a roundtrip on the wire (though you can batch them even in xlib...), and they say "most real applications will see less benefit than this" since that's the worst case - most applications do atom work at startup, not in the main use cycle, which is famously both async and buffered (it used to be a FAQ on xlib tutorials reminding people to run the event loop, and error handling is complicated a bit by it).

[taeric]

Though, even there, networks are far faster than they used to be. Especially for the size is windows they used to push.

[Schroedingersat]

Latency hasn't really improved. Dial up or isdn to nearby cities was 25-50ms. Same as I get with hfc or 5g. Cable was slightly better where it was available. International pings got much worse from australia in the 2010s but since improved roughly back to where they were.

Bandwidth has increased by 3 orders of magnitude though.

[icedchai]

Dial up latency was never that low. ISDN, yes, but traditional dialup modems were pretty bad. The analog-to-digital conversion introduced a couple hundred milliseconds of latency.

[Schroedingersat]

Latency hasn't really improved. Dial up or isdn to nearby cities was 25-50ms. Same as I get with hfc or 5g.

Bandwidth has increased by 3 orders of magnitude though.

[hakfoo]

I think one thing that sort of disappeared was the vision of thin clients everywhere. X11 is an obvious thin-client solution.

Thin client for home use seems like a winning proposition. Rather than giving the kids a Raspberry Pi 400 or garage-sale P4 when they want their own computer, you could hook up another X terminal to a large shared Ryzen box. The hardware gets more efficiently used, files can easily be shared and centrally backed up, and nobody ends up being the guy with the cast-off or otherwise inferior PC.

[moring]

I think quite the opposite happened, just not on X11 level. The web browser is essentially a thin client nowadays. The fact that you have full client-side scripting is one thing that was IMHO a bit underdeveloped in classical thin-client systems because with that you can mask network latency much easier (though, admitted, I don't know a lot about how X11 handles this).

[moomin]

Don't agree at all. The web browser is essentially a standardized computer on which to run your fat client systems like SPAs. The browser can run arbitrary computation locally.

[moomin]

The problem being that X thin clients back then were more powerful than desktop PCs at the time. Even now they're more expensive than a Raspberry Pi, so it's more economically efficient to buy one of those.

[kaba0]

Also, network latency has a quite imminent physical limitation, the speed of light. Serial computations do also have a limit, and we are close to it with current technology, but parallel execution doesn’t really have any, and GPUs take massive advantage of that. We can continue to increase resolution /frame rate basically arbitrarily (of course with very diminishing returns after a point)

[pjmlp]

There is some strange irony when watching people using quite expensive IBM X Windows thin client terminals to manage xterms, each being a different talk session.

[testermelon]

> These days a significant number of X11 apps just render _everything_ "server-side" as bitmaps and then send them over the wire to the client to composite them.

Inferring from the quotation, I take it you mean application server-side (instead of display server-side)? Just confirming.

[gunapologist99]

Exactly. If GP doesn't even know how X11 works, then the opinion probably shouldn't carry a lot of weight.

The "server" in X11 is the display that's sitting in front of you, not the application running on a remote workstation.

[retcore]

>which will give much better performance on low-bandwidth connections,

Er, IRIX was pushing 12 bits and alpha channel around over X on twisted pairs c.a. 1993.

[destructionator]

> since those protocols do damage detection, only sending updates of what's changed

So does X.

> and (lossy) compression.

This is legitimate though, the X protocol has no support for any kind of bitmap compression and it can sometimes be pretty painful. Though internets getting faster and faster too so it isn't necessarily a big deal especially since it does have bitmap caching and some display-side rendering capabilities, but it sure would be nice if you could send other formats on the wire.

[ciphol]

Is there a user-transparent way to run Gimp over RDP/VNC, similar to "ssh -X" for X11?

[razemio]

If I understand you correctly, yes. freexrdp has an option to render only a single window instead of the hole desktop. This works amazingly well and feels native. This is the trick WinApps uses.

You could either use WinApps or create your own script and add it to a desktop entry. Users can then open RDP Gimp like any other application without even noticing.

[cat_plus_plus]

Editing my photos over a layer of video compression artifacts doesn't sound fun. Web apps are a more reasonable replacement for X11, with browser client much more capable to do low latency local processing. The only problem is lack of easy support for local apps and LAN-distributed apps. Probably still easier to add than to support low input latency eventually consistant Canvas over X11 or VNC.

[kaba0]

There are lossy and lossless compression algorithms.

[ncmncm]

The roles of client and server being force-swapped is another perhaps unfortunate development.

[msh]

Why?

I think who should be client and who should be server is entirely context/application specific.

Sometimes I want to be able to connect to a server from any random client and continue the session.

[ncmncm]

Because now you never know which is which without a separate explanation. Might just as well call them A and B.