Wprs – rootless remote desktop for Wayland (and X11, via XWayland) applications • Hacker News Board

Re: Wprs – rootless remote desktop for Wayland (and X11, via XWayland) applications

#71

Post by epcoa » Sun, May 12, 2024, 5:47 PM UTC

Qwertious wrote: post #65

epcoa wrote: post #64

Earlier quoted context omitted.

> and at worst the Wayland devs decided Those goddamn Wayland devs and their individual free will. How dare they not continue to maintain this miserable, crusty old spec and continue to make their marketable skills less valuable. > Wayland could be nice, but its compositors require 10x the code that a WM would (which is why there aren't that many Wayland "WMs" Nah, this is an ecosystem maturity problem that is improv…

>Those goddamn Wayland devs and their individual free will. That's not the problem. The problem is all the heckling for everyone to switch to Wayland, and to make it default. And also pretending that reversing the "mechanism, not policy" wasn't a fundamental change of philosophy and was just "progress". And to be clear, by "at worst" I meant "this is the least-charitable interpretation". >Nah, this is an ecosystem ma…

> The problem is all the heckling for everyone to switch to Wayland

No one’s making you switch and Xorg is as open as it ever was. X is dying, slowly, that’s just a simple fact of the universe.

> Plenty of WM makers have just straight-up said they won't ever port their WM to Wayland

There are plenty of up and coming WM makers willing to produce suitable stacking and tiling WM/compositors. Active projects exist today.

> You mean like how X clients can read keyboard inputs?

No.. how every X client has global access to all of the X state of every client and how the only response to this are extensions that no one really uses for well established reasons.

> you need to sandbox every app anyway - at which point your sandbox should just interdict the X interface.

??

Re: Wprs – rootless remote desktop for Wayland (and X11, via XWayland) applications

#72

Post by epcoa » Sun, May 12, 2024, 5:58 PM UTC

1oooqooq wrote: post #66

epcoa wrote: post #53

Earlier quoted context omitted.

> I don't think that using extensions to support new features is much of a problem You are arguing issues that were not even raised. Read 1st para more carefully, especially the last sentence. > X11 doesn't inherently require that many round trips. The complaint was about excessive round trips, Why do NX, x2go, and xpra exist if the X11 protocol over high latency networks is such a peach? It's lovely that clients don…

it's funny you redhat employees parot the business decisions of your employer so adamantly. you did not address any point on your replies besides dismissal of them and trying to sho away the interlocutor. which you managed. but i guess it works, yall won on all fronts that was done. congratulations i guess.

Never worked for Redhat. I use Arch Linux, BTW and have for years. The rubes that willingly switched to systemd without even a drawn out flamewar.

Re: Wprs – rootless remote desktop for Wayland (and X11, via XWayland) applications

#73

Post by kaba0 » Mon, May 13, 2024, 7:09 AM UTC

1oooqooq wrote: post #67

epcoa wrote: post #39

Earlier quoted context omitted.

Somebody in a thread the other day lamented how almost always X clients are sensitive to network drops. And the suggestion is to use Xpra! (It’s “like tmux”) Xpra doesn’t forward X though, it is a rootless X server that then forwards everything as compressed bitmaps like VNC. It’s a nice homage to how awful X is even at its one oft purported benefit around here. X11 network transparency is a pretty poor technology, o…

and instead of x12 modernizing the network and access layer, breaking backwards compatibility with x11, they dropped those two features, and rewrote everything else which worked, and broke backwards compatibility. it's hard to defend.

I’m fairly sure the very maintainers of X11 knew more about the topic than you. And you get backwards compatibility with stuff like xwayland.

Re: Wprs – rootless remote desktop for Wayland (and X11, via XWayland) applications

#74

Post by cowboylowrez » Mon, May 13, 2024, 10:23 AM UTC

StillBored wrote: post #56

kaba0 wrote: post #19

Earlier quoted context omitted.

X being network transparent hasn’t been true for decades — no one uses xmotif and similar GUI libs, they just grab a buffer and paint stuff themselves, making the X protocol an inefficient format to carry bitmaps around. Local-first is the correct approach as the end computers are significantly more powerful than 30 years ago. Plus, we can transport bitmaps far more efficiently with compression, so it’s quite obvious…

"no one uses xmotif and similar GUI libs, they just grab a buffer and paint stuff themselves, making the X protocol an inefficient format to carry bitmaps around." While true for things like firefox, and GUI libs that think they know better than the host, its not ideal, and entirely dependent on the language/toolkit being used. And it's a side effect of X being too low level and not having a standard widget toolkit a…

I'm glad I found this thread, firefox really jumped the shark with remote x at some point, it always confused me why this happened all of a sudden. All I could find out from googling was the wayland thing and all of a sudden how x over the network wasn't cool anymore lol

Re: Wprs – rootless remote desktop for Wayland (and X11, via XWayland) applications

#75

Post by StillBored » Wed, May 15, 2024, 4:58 PM UTC

akvadrako wrote: post #57

StillBored wrote: post #55

Earlier quoted context omitted.

No, way, that can't be right....? Much of the reason RDP and WebGL work so well is that they send the raw command stream/assets to the rendering side rather than continuously sending a stream of compressed frame buffer data. RDP, for example, can send the raw video stream being played, or recompress it, and send it rather than trying to render it to the screen and then recompress the resulting output, which is what y…

RDP hadn't worked that way for years. https://techcommunity.microsoft.com/t5/security-compliance-a... And we do have hardware encoding / decoding. The latency is quite reasonable, like 15ms in total, so modern solutions like parsec work for any app, including games and CAD.

That stuff was just appearing when I last worked on an RDP client for a mobile platform. At the time, it depended on the application/client region and the bandwidth/capability requests from the client. AKA, it would kick in for an application that was just dumping a predrawn buffer but not for applications that were still using the Win32 API extensively unless there were additional graphical operations going on (e.g., transparent windows).

And that is part of the fun of RDP, it has an immense number of different ways of accomplishing the end goal, and newer methods were being added to compensate for the way applications themselves were being written while the older ones remained. It was a long road of dealing with edge cases, with certain applications not rendering properly.

AKA, use a 3rd party library to draw all the GUI widgets and windows didn't have any alternative but to come up with a better way to compress and send those updates. And the last time I ran an RDP client to Windows, this stuff was still visible; older win32 applications were fast/responsive, and things like Firefox would just chug every time it hit a web page that was doing any kind of dynamic content (think scrolling an ad).