[HN Gopher] Xpra: Persistent Remote Applications for X11
___________________________________________________________________
Xpra: Persistent Remote Applications for X11
Author : cl3misch
Score : 180 points
Date : 2024-07-08 09:15 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| darau1 wrote:
| The description makes me think this can reproduce a cool workflow
| demonstration I saw a few years ago on reddit[1].
|
| [1]:
| https://www.reddit.com/r/unixporn/comments/k1eu0n/durden_wor...
| vidarh wrote:
| You could probably tweak something like Barrier for the
| kvm/cursor move, and use XPRA to move the window, sure. No idea
| how much/little work it'd be but doesn't seem like it should be
| all that complex.
| forgotpwd16 wrote:
| There're a few options (including outdated) that can be used to
| replicate this workflow. Easiest being winswitch (which is
| based on xpra).
| spencerflem wrote:
| This was very cool, and is made in Arcan! https://arcan-fe.com/
| a project I just recently discovered and am very excited about
| Filligree wrote:
| Okay, but X11 is deprecated. Is there a modern version?
| jacknews wrote:
| maybe this: https://github.com/wayland-transpositor/wprs
| forgotpwd16 wrote:
| Deprecated according to Red Hat maybe but very much still
| relevant.
| blahgeek wrote:
| I don't think the existence of Wayland means X11 is deprecated.
| Lots of people (including myself) would prefer the perfectly
| working X11 than the feature-incomplete backward-incompatible
| "modern" wayland
| necrotic_comp wrote:
| I haven't yet seen any compelling reason to move off of X11.
| It's been years since I've checked - what's the current state
| of the art ?
| ChoHag wrote:
| > what's the current state of the art ?
|
| Wayland is going to make 2024 the year of Linux on the
| Desktop!
|
| Any day now...
| LelouBil wrote:
| Yeah, but it is slowly getting better.
|
| Not advocating for 2024 (or 2025) but I still think
| someday it will, having seen multiple usability and
| feature improvements. (Not only talking about wayland
| here)
| intelVISA wrote:
| I thought it was already the year of Linux on the
| Desktop??
|
| Jokes aside if you can avoid anti-cheats (rootkits) DXVK
| makes a lot of Windows workflows very accessible on
| Linux.
| vidarh wrote:
| For me, the year of Linux on the Desktop was '94. It's
| been my main desktop at home ever since, and for wor as
| well the majority of time - but with some obnoxious
| detours.
| account42 wrote:
| > DXVK makes a lot of Windows workflows very accessible
| on Linux.
|
| And it has achieved that with X11.
| SSLy wrote:
| https://github.com/ValveSoftware/gamescope is the one
| actually competent wayland WM.
| p_l wrote:
| Noticeably it doesn't export Wayland to applications
| running underneath unless you enable an experimental
| flag, and half the reason for its existence is that it
| can be entirely bypassed by related Vulkan layer
| extension.
| Gormo wrote:
| And it works great as a standalone X11 server too.
| rcxdude wrote:
| It's deprecated by the people who wrote it, and AFAIK no-one
| else has taken up the task of maintaining it. Doesn't mean
| you can't use it (I still use it still, thanks to said
| breakage), but it's not exactly thriving.
| vidarh wrote:
| It's still seeing regular releases. It's split into modules
| now, but the xorg-server module last had a release in
| April, I think, with multiple contributors, and at least
| two people are issuing release announcements.
|
| Maybe I'll consider Wayland again in a few years (though,
| who knows, by then maybe I'll have fallen for the
| temptation to write my own X server too...), but for now,
| Xorg works, receiving fixes, and doesn't require me to
| change anything else in my workflow for no good reason.
| seba_dos1 wrote:
| > It's still seeing regular releases.
|
| With very limited scope. There's already hardware out
| there that will likely never be properly supported by
| Xorg.
|
| Though Xwayland - and hence a big chunk of Xorg - will,
| of course, still live a long life.
| vidarh wrote:
| If that affects me one day, maybe I'll care about that. I
| doubt that'll be a concern until sometimes next decade at
| the earliest for my use.
| p_l wrote:
| Unfortunately Wayland means increased fragmentation in
| the hw support, not less :(
| Gormo wrote:
| Considering that hardware vendors are typically writing
| and upstreaming their own drivers, I don't see how that
| could be.
| llm_trw wrote:
| Xorg Foundation are not the people who wrote X, they are
| the last in a long line of maintainers.
| jrm4 wrote:
| Always an odd argument? Sometimes software is just
| finished.
|
| Shoutout to Openbox
| Gormo wrote:
| This is false. Xorg is being actively maintained, and its
| git repos are constantly receiving new commits.
| jrm4 wrote:
| Even funnier, I have a bunch of rando computers and servers,
| some with friends and family with different distros...and at
| any given time, I'm not sure which I'm using.
|
| (Which I suppose means that Wayland has matured a
| lot..finally, but still)
| yrro wrote:
| Local and mote apps using the X11 protocol to connect to a
| local X server (such as Xwayland) isn't going anywhere.
| guilhas wrote:
| Wayland is still catching up
| account42 wrote:
| Oh god, has the "rewrite it in rust" crowd finally learned
| about wayland?
| k_roy wrote:
| Is this either rust or wayland? Nope. Memes are fun though.
|
| Though I have no problem with anything being rewritten in
| rust. It's usually just as fast, and more importantly,
| freaking modern. Look at `lsd` or `ripgrep`
|
| Python 81.7%
|
| Cython 14.9%
|
| Shell 1.1%
|
| Roff 0.9%
|
| Rich Text Format 0.7%
|
| C++ 0.2%
|
| Other 0.5%
| ranger_danger wrote:
| I wish rust people spent their time writing software instead
| of going around telling other people to do the job for them.
| They only manage to get others annoyed with this attitude.
| whytevuhuni wrote:
| Could I get an example of this?
| jrm4 wrote:
| At the risk of threadjacking, I'd still love to have a real
| conversation about how and why this Wayland thing happened (and
| is still arguably happening) so _badly_.
|
| Specifically, how -- again, in LINUX-LAND -- a whole bunch of
| people decided, "nah, we're going to go ahead and break the
| HELL OUT OF backwards compatibility this time, even though we
| pretty much never do this."
| asveikau wrote:
| Linux actually does this a lot. Jwz called it "Cascade of
| Attention-Deficit Teenagers" more than 20 years ago,
| describing GNOME.
|
| Look at audio. PulseAudio is mostly pointless and over-
| engineered. Breaks a lot. You could say the same about ALSA
| even. FreeBSD meanwhile is still using the OSS API that Linux
| was on in the late 90s...
| jrm4 wrote:
| Ha, I'm showing my age. You're right, my brain is still at
| "Linux around the year 2000."
|
| That being said, it's still the same problem.
|
| And I think that's why I find it odd that I haven't heard
| the argument more plainly stated like:
|
| "Oh look -- right around when Linux became mainstream, it
| began to get worse in precisely the same ways proprietary
| stuff was already bad. Probably a result of more business
| involvement, but how can we counter it."
| rwmj wrote:
| PulseAudio has already been abandoned, the new thing is
| Pipewire.
|
| The specific issue with OSS was that it was never part of
| Linux and then with OSS 4 they made it proprietary, which
| killed it off entirely as far as Linux users are concerned.
| (FreeBSD cloned it instead.)
| asveikau wrote:
| Oh yeah. I should have noticed that because on the Debian
| machine I set up for my daughter, audio suddenly broke,
| and it started working again when I removed pipewire.
|
| No joke, if you remove the new thing stuff magically
| starts working again.
| nathanasmith wrote:
| I had to restart Pipewire just this morning when audio
| randomly stopped working. It's funny as this is the first
| time it happened then an hour later I'm reading in this
| thread about Pipewire acting funny on other people's
| computers.
| p_l wrote:
| in my experience, unlike pulseaudio, pipewire is way
| stabler and usually works fine with less involvement.
|
| ... except when you have accidentally ended up with half-
| pipewire, half-pulseaudio setup due to half-forgotten
| instructions that were no longer applicable.
| asveikau wrote:
| Maybe my dist-upgrade got it into such a state. I'll try
| to check that out.
| p_l wrote:
| I ended up solving a similar case for someone else, where
| ultimately different programs were fighting over control
| of the sound devices themselves.
|
| I have to say, that pipewire under NixOS had been easier
| to deal with than both pulseaudio and ALSA on crappy
| internal sound devices (i.e. ones requiring dmix and the
| like). It's nearly as plug&play as ALSA on "proper"
| soundcard was (like when I got a Dell Precision to work
| with that somehow had a Creative Audigy with 256 channel
| sound, so no need for dmix at all...)
| jwilk wrote:
| > The specific issue with OSS was that it was never part
| of Linux
|
| Huh?
| asveikau wrote:
| Iirc there was a version in the kernel tree, then
| "upstream" if you could even call it that developed it
| further (OSS 4.0). I think there was a company behind it
| and a nonfree license. Obviously that was a no-go for
| inclusion into mainline Linux.
|
| But alsa was/is also enormously complicated with a huge
| library, user mode plugins and whatnot. It reminds me of
| a common problem that people have where they think API
| and implementation are one and the same, and that you
| cannot swap out a different implementation keeping the
| simple API. People would say you need alsa because it
| does software mixing, but the lack of software mixing
| wasn't an OSS API problem, it was a problem with how it
| was implemented.
| progmetaldev wrote:
| Open Sound System (OSS), rather than Open Source
| Software, if I'm reading you right. I only recall because
| I've been toying with sound software for decades, trying
| to get various synths and music composition applications
| working. Apologies if that didn't address your confusion.
| vundercind wrote:
| My best guess is it was designed to make it a bad idea to run
| anything but Red Hat with Gnome if you need anything
| resembling stability.
|
| If it wasn't designed for that on purpose, I'm pretty sure
| it's at least why Red Hat ran so enthusiastically towards it.
| kmeisthax wrote:
| There's a few related answers to your question, so I'm going
| to meander a bit and hope you can follow along.
|
| First off, backwards compatibility wasn't actually broken.
| X11 apps work fine under Xwayland. All the weird bikeshedding
| that happens in Wayland isn't as important because we have
| working compatibility bridges and all the old stuff still
| works.
|
| Second, "don't break userspace" is specifically a Linux
| kernel policy. The only other organization in FOSS that has
| such a slavish devotion to backwards compatibility is
| WINE[0]. Desktop environments are perfectly fine with, at the
| very least, breaking ABIs, because you can just recompile the
| ocean. I suspect this is the Free Software equivalent of
| "firing shots to keep the rent down" - i.e. making the
| software neighborhood undesirable for proprietary software
| vendors who will have to deal with these annoying and
| arguably pointless transitions every couple of years.
|
| The reason why we needed to get off X11 is very simple: X11
| is an extremely poor fit for modern hardware. The protocol
| supports simple drawing commands and image display, that's
| about it. Modern user interfaces want applications that draw
| onto GPU layers, composite them, and then present a final
| image to a compositor to be displayed to the screen. You
| _almost_ can build that on X11 (modulo some frame tearing),
| but it 's a pain in the ass and requires adopting a lot of
| extra protocols plus XGL which breaks network
| transparency[1].
|
| The motto of X11 is "mechanism, not policy". The way this is
| accomplished is by presenting the entire desktop as a tree
| structure of windows that any client can mutate. Any widget
| toolkit can then build the experience it wants on top of that
| tree structure. The problem is that this also makes writing
| keyloggers and RATs trivial. X11 doesn't sandbox
| applications, so even if you lock down a process every other
| way, they can still do horrible things to other X clients and
| Xorg won't stop them.
|
| Wayland fixes this by tightly restricting what clients are
| allowed to do to the desktop. Applications get to present
| their own windows, sure, but they can't touch other windows
| unless a specific extension is provided for their use case
| and the compositor allows the application to use it. In other
| words, Wayland is "policy, not mechanism". The downside is
| that now we have to codify all the slightly-different ways
| each widget toolkit, window manager, and desktop environment
| has done things under X11. This has resulted in an explosion
| of extensions, many of which overlap because they were made
| by different DEs. Wayland can of course create standardized
| versions of these extensions, but each standardization is an
| opportunity for bikeshedding.
|
| This leads into my favorite way to tell if an application is
| Wayland or X11: launch Xeyes. If the eyes track your mouse
| over the application's windows, it's X11. Wayland doesn't
| have a protocol for mouse tracking, so Xwayland can't report
| where the mouse cursor is, unless it's on top of a Wayland
| window that it's already getting events for - namely, the app
| you're wondering about.
|
| Ok, I suppose that _is_ a backwards compatibility break.
|
| [0] This also means the most stable UI toolkit on Linux is
| actually USER.dll.
|
| [1] In fact, I suspect this is why Wayland was so willing to
| casually toss that out. GPUs and network transparency are
| allergic to one another.
| drdaeman wrote:
| I don't think that's the issue with Wayland. X11 has
| fundamental design flaws, Wayland happened because of it.
|
| I believe the question is why Wayland happened so _badly_.
| Sure, nVidia shenanigans are contributing to bad fame, but
| arguably that 's not the issue with Wayland. However,
| Wayland fixes some of X11 design flaws but ignores others -
| or even introduces new ones.
|
| But, for example, HiDPI is a mess in X11 - for (I assume)
| pretty obvious reasons of not having HiDPI back in the day.
| Weirdly, Wayland does nothing to make things right -
| instead it just gives up on the DPI concept altogether as
| if physical dimensions simply aren't a thing[1]. While this
| sort of solves some of the issues X11 had (although,
| scaling works with X11 too), it's just wrong.
|
| Then there are a bunch of other controversial design
| decisions (like client-side decorations - as if consistency
| wasn't a problem already) that are more nuanced.
|
| ___
|
| 1) Or so I believe - I could be wrong. I just wanted to
| configure DPI for my monitors hoping that it would help me
| to have things sized correctly, and have read somewhere
| that it's not a thing in Wayland and all they have is scale
| factors.
| ndiddy wrote:
| Wayland happened so badly compared to e.g. the Systemd
| transition or the Pipewire transition because it was
| developed by Xorg developers who had spent years dealing
| with its complexity and countless regressions caused by
| bugfixes breaking obscure behavior that clients depended
| on. As a result, they swung too far in the other
| direction. They came out with a minimal protocol where
| all the heavy lifting was done in each compositor rather
| than having a single common implementation. Most
| importantly, the base protocol was completely unsuitable
| for nontrivial programs. Features such as screen sharing,
| remote desktop, non-integer scaling, screen tearing, or
| even placing a window in a certain position were not
| supported.
|
| Because Wayland's base protocol was unable to replace
| X11, virtually nobody adopted it when it was initially
| released in 2008. The subsequent 16 years have been taken
| up by a grueling process of contributors from various
| desktop environments proposing protocol extensions to
| make Wayland a workable solution for their users. This
| has resulted in endless bikeshedding and requires
| compromise between different stakeholders who have
| fundamentally different viewpoints on what the Linux
| desktop should even be (GNOME vs everyone else). As an
| example, the process for allowing a client to position
| its own windows has been ongoing for over two years, and
| has led to multiple proposed protocol extensions with
| hundreds of comments on each.
|
| The transition would have been much smoother if Wayland
| had the same "mechanism over policy" philosophy as X11
| and allowed for software to easily be ported to it, but
| long-term that could have caused the same issues that the
| Xorg maintainers were facing when they created Wayland.
| llm_trw wrote:
| >the Systemd transition or the Pipewire transition
|
| Both of these were shit shows which only look good now to
| people who were around when they were happening.
| uecker wrote:
| The story that X11 somehow forces programs to use outdated
| drawing primitives was never really true as a long as I can
| remember. Compositing on X11 exists.
|
| In principle, it is an extensible generic remote buffer
| management framework. As such, it could be extended
| indefinitely without every breaking backwards and forwards
| compatibility and is also a good fit for modern hardware
| that essentially deals with remote buffers on the GPU. As
| someone doing HPC programming on GPU, network transparency
| and GPU are definitely not at all allergic.
| temac wrote:
| And chose an architecture really interesting where everybody
| will recode an half-baked version of the work-in-progress
| protocol so each desktop-env/window-manager will have
| different compatibility characteristics; and where tons of
| actual implementation mix the graphic server with the
| desktop-env/window-manager so that crashes are extra fun.
| uecker wrote:
| I think a couple of people hired to to work on Linux graphics
| did not like dealing with legacy code (who does?) and somehow
| convinced their incompetent managers that everything has to
| be rewritten.^1 This went just like most "let's just rewrite
| it and it will be much simpler and better" IT projects. Now
| 15 years later or so we have a fundamentally inferior
| replacement (with probably nicer code though) which still
| misses essential features and plays catch up a, a
| simultaneously a serious lack of investment into maintenance
| of X, and also a lack of investment into user visible
| features in apps (I think gnomes pdf viewer gets its third
| rewrite, but still can't play embedded videos in presentation
| mode).
|
| A lot of the user community was fooled into believing that
| Wayland would make graphics and gaming much better any day
| now ^2, which never really was based on sound technical
| arguments.
|
| ^1 This was roughly the time when everybody wanted to build
| new phone or tables operating systems to capitalize on an
| emerging mobile market. So maintaining stability for the
| desktop wasn't a priority.
|
| ^2 With grotesque nonsense claims about X such that the old
| drawing API slow apps down even though they are unused, etc.
| Those "arguments" were endlessly repeated and you can still
| see this even here, also everybody who ever implemented a GUI
| application in Linux should realize that this can not be
| true.
| okanat wrote:
| That happens a lot in Linux world since people design
| software in extremely limited way in the name of simplicity
| and "Unix philosophy" which limits their composability.
|
| So only interfaces became limited to what's available at that
| moment and the limited set of Unix software abstractions.
| Those abstractions are also made extremely use case specific
| even though there are opportunities to unifiy them like
| Android did with Binder, Windows did COM and dotnet.
|
| Of course technical difficulties of designing efficient and
| long-term surviving interfaces also play a role. There are
| too many hobbyists in the Linux desktop world and too few
| professionals who also have to work with hobbyists. Many
| contributions to Linux desktop happen when people are
| studying and then they leave. This creates disincentives to
| design long-term systems because they take too long and they
| are a slog to design and keep up-to-date.
| spookie wrote:
| If you do any work with video cameras you will understand
| Wayland isn't there yet.
| 4ad wrote:
| Last I checked this didn't support HiDPI, a technology invented
| over 10 years ago.
| adrian_b wrote:
| I have not used Xpra, so I do not know if it has any problems
| with this, but a priori I do not see why an application like
| Xpra would need to be aware about the screen resolution. That
| should be handled by the X clients and servers.
|
| I have used only 4k monitors for more than 10 years in Linux
| and the only applications with which I frequently had problems
| were various programs written in Java by morons, which were
| usually proprietary applications and some times quite
| expensive, but they lacked such elementary customization
| features like allowing the user to change the font, or at least
| its size, while failing to use the configuration settings of
| the graphic desktop, i.e. the value set for the monitor DPI,
| like all non-Java programs.
| simcop2387 wrote:
| The way Xpra works is that it's both a server and client in
| it's own right. So it needs to be aware for the final client
| involved to be able to learn about it from the other side of
| the chain, so it does need to be aware of it in order for
| applications to know that they need to adjust themselves.
| What this results in is that the client you're running
| through Xpra will just assume it's a normal 96 DPI display
| from yesteryear usually. I think you can do some stuff to
| tell Xpra that it should be a higher DPI but that'll also
| make it so that the application will be gigantic on a low dpi
| display, something that's pretty typical for X11 since it
| doesn't properly support mixed DPI environments (i.e. a
| laptop screen that's high dpi and an external monitor that is
| low dpi).
| ndiddy wrote:
| X11 supports mixed DPI with the RANDR extension.
| Applications can use the per-monitor information provided
| by RANDR to get the DPI information for each output, and
| use this to calculate font and widget sizes. Everything
| looks nice as long as you don't have a window spanning
| multiple screens. The problem is that while Qt has
| supported this functionality since 5.9, GTK seemingly has
| no interest in implementing it and most other toolkits or
| raw Xlib programs don't support it either.
| superkuh wrote:
| Similarly, the waylands still don't support screen readers for
| the differently abled, a technology invented longer ago.
| mook wrote:
| Last I checked (somewhat less than ten years ago), it did do
| things with DPI. Note that if you were using it with a sorry
| distro-packaged version it might have been broken because
| proper DPI support requires a patched X11 dummy video driver or
| something along those lines, and if you had an unpatched one
| DPI stuff didn't work.
| BLKNSLVR wrote:
| I tried Xpra for remote applications some four to five years ago
| when I migrated from Windows to Linux and needed a Remote Desktop
| (type) alternative.
|
| I stuck with it for a while in advance of numerous other options,
| until I found NoMachine - which doesn't do remote applications
| but does do full remote desktop and has the closest 'feel' to
| being local-machine than anything other than Windows Remote
| Desktop.
|
| I (ironically?) dislike Microsoft just that little bit extra for
| making Remote Desktop so damn good whilst progressively
| destroying the Windows experience.
|
| I would like to try Xpra again, but I've got a growing list of
| "I'd like to try that's" that even the top priorities only get
| small bites taken out of them per week / month - and my current
| workflow is pretty good.
| KronisLV wrote:
| For remote desktop use cases, I've found RustDesk to be pretty
| good, especially if you can self host the relay:
| https://github.com/rustdesk/rustdesk
|
| I especially enjoyed that I can use AV1 for the encoding
| (better quality even at lower bitrates), being able to switch
| resolutions easily and also the response times being pretty
| quick.
| 2Gkashmiri wrote:
| Haah.
|
| No need for a relay.
|
| I have a zerotier network for my Machines and it works
| "locally".
|
| Rock solid. Public network is pretty crummy.
|
| With your zerotier / tailscale, you have not 100% control and
| no overhead of a relay
| bogwog wrote:
| I prefer MeshCentral. Not only does it work better, it has
| way more features. For example, you can browse the remote
| system's files and use a terminal without having to stream
| the graphical environment. It also has some Intel ME
| integration which I haven't really looked into.
|
| RustDesk is easier to get started with though, especially if
| you're coming from TeamViewer. However I've always been a
| little wary of RustDesk. The dev is (was? Haven't kept up)
| anonymous and seems to be some Chinese company. Even ignoring
| the China ties, I wouldn't trust an anonymous dev with
| sensitive software like this.
| hparadiz wrote:
| KRDP Server is getting there. I was able to play Civ VI over it
| from my Macbook Air with decent fps.
| lostmsu wrote:
| Sadly you first have to login locally in order to use it. Or
| has that changed yet?
| yaantc wrote:
| You may want to try x2go. It uses the older NX protocol version
| 3, while NoMachine is at version 4. It's good enough for my use
| case, and support remote applications just fine: this is how I
| use it.
| jamesfmilne wrote:
| NICE DCV is a good alternative if you don't mind paying. I've
| found the image quality, latency and multi-monitor support to
| be better than NoMachine. You can get a permanent licence for
| $180.
|
| https://www.nice-dcv.com
|
| They are owned by Amazon Web Services.
| intelVISA wrote:
| NICE DCV is very solid but its licensing and links to AWS
| pushed me to write a replacement (it's just NVENC over UDP)
| one bored weekend... will have to OSS it some day.
|
| There's also RustDesk that looks great but I can't say I've
| used it yet.
| djfergus wrote:
| Would love to hear more details and see the code.
|
| I've found NICE DCV to be more performant on low end
| clients (eg chromebooks) maintaining good responsiveness vs
| RDP.
| PhilipRoman wrote:
| xrdp + rdesktop is my current daily driver for this
| metadat wrote:
| Xrdp is really good.
|
| I'm amazed by the quantity of different Linux remote desktop
| solutions covered in this thread. Is the fragmentation a good
| sign of a healthy ecosystem?
| temac wrote:
| I find xrdp quite slow esp compared to a Windows RDP
| server. This is with the xrdp that comes with Debian 12.
| Maybe newer versions are faster.
| metadat wrote:
| I'm using the same as you - Debian 12. The only snag I've
| noticed is that it's pretty easy to make a session crash,
| at which point you lose the entire desktop.
| dmd wrote:
| NoMachine absolutely does do remote applications. I use it for
| that every day. Instead of "Create a new virtual desktop",
| choose "Create a new custom session" and under Application "Run
| the following command" (the program you want to run) and under
| Options "Run the command in a floating window".
| FranGro78 wrote:
| Perhaps it would make you feel a little better to learn that
| RDP was created from Citrix's ICA protocol during some cross
| licensing between the two companies.
|
| I worked on using hardware acceleration to replace parts of the
| ICA client application's raster functionality for "thin client"
| devices a lifetime ago.
| jesprenj wrote:
| Ohhh, that's what it's for! I use it for scaling x11 apps with
| the run_scaled script that's shipped with xpra (:
| jimbosis wrote:
| I'm half-heartedly trying to RTFM of 'xpra', but haven't found
| the 'run_scaled' script yet. If it's not too much trouble, can
| you please reply with the commands you use to scale an X11
| program?
|
| (I'm on Devuan Daedalus 5.0, ~= Debian Bookworm 12.0.)
|
| (I currently use 'xzoom' to scale X11 programs, but it's a
| little kludgy.)
|
| EDIT: Single quotes for all program names. Bookworm, not
| Bookwork.
| elitepleb wrote:
| https://github.com/kaueraal/run_scaled
| kaueraal wrote:
| This is the old, original version by me. xpra itself ships
| nowadays an improved version.
| kaueraal wrote:
| Xpra itself ships this script, but Debian's version is quite
| old. You need at least 4.1 and Debian Bookworm seems to have
| 3.1. Xpra seems to have an own apt repo you can probably use.
| alchemist1e9 wrote:
| Once you have GPU server side encoding and client GPU decoding
| all working correctly with NVENC end to end there is nothing like
| it in terms of speed and performance for remote work. With a
| reasonable ping latency like 20-30ms and quality link a user on a
| cheap gaming laptop connected to a decent beefy server with the
| GPU encoding working can perceive the remote browser window as
| faster than their local browser.
| silasb wrote:
| Any good guides for this?
| alchemist1e9 wrote:
| This is going to be very unhelpful for most but I use nixpkgs
| and end up applying some build tweaks to make sure all GPU
| capabilities are properly supported.
|
| That said I know there is newest version 6 which
| Ubuntu/debian users should be able to add the xpra apt
| sources to get and it might all just work out of the box. I
| should check.
| coretx wrote:
| The first one to dump this into flutter will probably be onto
| something
| amelius wrote:
| If you want to run remote applications in a browser, you could
| use:
|
| https://github.com/Xpra-org/xpra-html5
| gdevenyi wrote:
| The SSH support in the GUI application isnt very good which
| precludes me recommending it to my users sadly.
| aidenn0 wrote:
| I find it really annoying that it seems to default to paramiko
| for ssh support. I already have all of my ssh setup via openssh
| (e.g. jumphosts, identity files, connection multiplexing), and
| I have to pass "--ssh=ssh" to get any of that to work.
| caohongyuan wrote:
| oh my god
| beardog wrote:
| I use xpra to run apps in VMS but seamlessly render them on my
| desktop. Allows me to have a qubes type workflow without using
| qubes. Probably not quite as secure, but you can disable features
| for untrusted servers.
| fb03 wrote:
| Quick question: Why would you need Xpra for this, or what are
| the advantages of Xpra over normal X forwarding?
| jrm4 wrote:
| This might be a good place to ask this:
|
| So, the idea of Firefox Sync is almost cool, but what I'd like is
| _literally_ everything EXACTLY "synced," down to the current
| state of every tab.
|
| Something like this feels like it should do it, but I've tried
| this and other things, and it just didn't work all that
| seamlessly.
|
| Has anyone accomplished anything like this for browsers and use
| it regularly?
| organsnyder wrote:
| Seems like a remote desktop solution is always going to be
| better at this--I'd imagine there's a long tail of weird
| website behavior trying to sync browser state.
|
| Or just carry a laptop.
| toenail wrote:
| I rsync my entire firefox profile from workstation to
| workstation, sync sucks.
| jd3 wrote:
| I sync my entire firefox profile to multiple machines using
| syncthing
|
| https://tonsky.me/blog/syncthing/
|
| https://syncthing.net/
| jrm4 wrote:
| That's funny, I'm a heavy user of syncthing but never thought
| to try this. It doesn't get weird opening different
| executables on different machines?
| jd3 wrote:
| It's been awhile since I've touched the config, but I think
| I ignore arch-specific executables using
| https://docs.syncthing.net/users/ignoring.html.
|
| I also haven't checked my Windows machine that it syncs
| with recently, so there might be issues on the latest ff
| etc etc. I started doing this with SeaMonkey, whose profile
| is simpler conceptually since it's still built on top of an
| old firefox legacy esr.
| nemoniac wrote:
| Are there any security implications of running this over ssh?
| necheffa wrote:
| That depends on how you authenticate. If you pass your SSH
| password on the command line then anyone on your machine doing
| a `ps` at the right time could see your password.
|
| I find using a ssh-agent to load password protected SSH keys
| works best.
| JeremyNT wrote:
| If you're only working on Linux, you almost surely want waypipe
| [0] instead of xpra. If you need support for other platforms,
| though, xpra is still a pretty good solution.
|
| [0] https://gitlab.freedesktop.org/mstoeckl/waypipe
| amelius wrote:
| Uh, only if you want to use Wayland.
| simoncion wrote:
| Yep. Despite what Redhat would have folks believe, xorg works
| fine and will continue to work fine for the foreseeable
| future.
|
| Plus, if one wants things like functional screen readers,
| suitable-for-video-games Vulkan frame pacing [0], and many
| other things that you'd think would be table stakes for a
| project that's been running for at least 15 years, one's only
| choice on Linux is xorg.
|
| [0] The only reason the Steam Deck isn't a disaster is
| because Valve has been carrying a patch for a "Make frame
| pacing not garbage" extension that the Wayland people have
| been refusing to merge in for the past two+ years.
| llmblockchain wrote:
| I am running linux machines and I have one headless machine. I
| need to keep a browser running in that machine and occasionally
| check on it (see what it's doing, and possibly fix things in the
| browser). Would Xpra let me do that from a remote machine?
| necheffa wrote:
| Yes.
|
| With Xpra you have a headless X session on the remote machine
| and you "detach" and "attach" to it from the client. So
| whatever X applications you leave running will be right where
| you left them.
| paulirish wrote:
| I use this instead of Chrome Remote Desktop and really appreciate
| the seamless window integration. It does, however, take some work
| to get it working smoothly.
| amelius wrote:
| I use it to run software that is too new for my Linux distro
| inside a headless VM.
|
| Package management sucks, and this is my way to deal with it.
___________________________________________________________________
(page generated 2024-07-08 23:00 UTC)