Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xpra: Persistent Remote Applications for X11

github.com

Post reply on HN
Print view View original

131–140 of 142 posts

Re: Xpra: Persistent Remote Applications for X11

#131

Post by aidenn0 »

kragen wrote: post #121
aidenn0 wrote: post #119

Earlier quoted context omitted.

Since xpra takes a sub-command as the first arg it's more like: : xpra_cmd="$1" shift exec /usr/bin/xpra "$xpra_cmd" --ssh=ssh "$@" And I don't see how that helps with using the GUI (like the comment I replied to). Also, defaults matter.

can't you put the flag before the subcommand? and can't you pass the flag when you launch the gui? i haven't been using it lately so i don't remember defaults do matter, but defaults can be changed. if it only takes a four-line shell script to change them, they don't matter much

> can't you put the flag before the subcommand?

The manpage implies you can't, but I tested and you can.

> and can't you pass the flag when you launch the gui?

I just tested and passing the flag when you launch the gui has no effect.

Re: Xpra: Persistent Remote Applications for X11

#132

Post by kragen »

aidenn0 wrote: post #131
kragen wrote: post #121

Earlier quoted context omitted.

can't you put the flag before the subcommand? and can't you pass the flag when you launch the gui? i haven't been using it lately so i don't remember defaults do matter, but defaults can be changed. if it only takes a four-line shell script to change them, they don't matter much

> can't you put the flag before the subcommand? The manpage implies you can't, but I tested and you can. > and can't you pass the flag when you launch the gui? I just tested and passing the flag when you launch the gui has no effect.

hmm, that last item seems like a pretty serious flaw; it makes the default matter a lot

Re: Xpra: Persistent Remote Applications for X11

#133

Post by p_l »

simoncion wrote: post #110
amelius wrote: post #107

Earlier quoted context omitted.

Uh, only if you want to use Wayland.

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 De…

SteamDeck uses gamescope which, outside of defaulting to provide XWayland as the actual API to applications, uses special Vulkan extension to essentially remove compositor from the pipeline other than things like performance overlay, making DXVK and others render as close to direct to scan out as possible.

Re: Xpra: Persistent Remote Applications for X11

#134

Post by p_l »

asveikau wrote: post #97
jwilk wrote: post #95

Earlier quoted context omitted.

> The specific issue with OSS was that it was never part of Linux Huh?

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 i…

ALSA started replacing OSS on linux before software mixing became as critical as it ended up, because people still often had proper sound cards with multiple channel hw mixers.

The assumption that you could punt software mixing to hardware or deal with limitation of only one program accessing the audio at a time took a hard hit when Intel HDA pretty much decimated presence of such hardware on PCs (AC'97 was much less pervasive for various reasons)

Re: Xpra: Persistent Remote Applications for X11

#135

Post by totaam »

kragen wrote: post #117
aidenn0 wrote: post #61

Earlier quoted context omitted.

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.

this sounds like something you can fix with a two-line shell script #!/bin/sh exec /usr/bin/xpra --ssh=ssh "$@"

You're making it way more complicated than it should be. Just edit the defaults in `/etc/xpra/conf.d/40_client.conf`: https://github.com/Xpra-org/xpra/blob/eedf34ecef3a04d0867709... (or your personal defaults in `~/.config/xpra`)

Re: Xpra: Persistent Remote Applications for X11

#136

Post by totaam »

aidenn0 wrote: post #119
kragen wrote: post #117

Earlier quoted context omitted.

this sounds like something you can fix with a two-line shell script #!/bin/sh exec /usr/bin/xpra --ssh=ssh "$@"

Since xpra takes a sub-command as the first arg it's more like: : xpra_cmd="$1" shift exec /usr/bin/xpra "$xpra_cmd" --ssh=ssh "$@" And I don't see how that helps with using the GUI (like the comment I replied to). Also, defaults matter.

No, the subcommand does not need to be the first arg.

Re: Xpra: Persistent Remote Applications for X11

#137

Post by totaam »

aidenn0 wrote: post #131
kragen wrote: post #121

Earlier quoted context omitted.

can't you put the flag before the subcommand? and can't you pass the flag when you launch the gui? i haven't been using it lately so i don't remember defaults do matter, but defaults can be changed. if it only takes a four-line shell script to change them, they don't matter much

> can't you put the flag before the subcommand? The manpage implies you can't, but I tested and you can. > and can't you pass the flag when you launch the gui? I just tested and passing the flag when you launch the gui has no effect.

If you don't want to change the global defaults (in `/etc/xpra`), or your personal config (`~/.config/xpra`), you should be able to stick `ssh=ssh` in a `$HOST.xpra` session file and the launcher should honour it when you open the file / double-click on it. (add `autoconnect=true` and the launcher won't be seen unless the connection fails)

Re: Xpra: Persistent Remote Applications for X11

#139

Post by totaam »

gdevenyi wrote: post #33

The SSH support in the GUI application isnt very good which precludes me recommending it to my users sadly.

Perhaps your users don't have the same abilities with ssh? The reason why xpra switched to paramiko as default ssh implementation is because it makes it possible to integrate (cross platform too) with the GUI so that asking for passphrases or passwords can be handled by the xpra process itself (it may already have the password or it may delegate to pinentry or gpg agent or putty agent or whatever). This also means that ssh errors can be handled much more gracefully - natively in the code. With openssh launched as a subprocess, the user interface is non-existent, and when the ssh process fails, all the xpra process sees is a dead process with a non-zero exit code - which is much more difficult to handle gracefully.

Re: Xpra: Persistent Remote Applications for X11

#140

Post by kragen »

totaam wrote: post #135
kragen wrote: post #117

Earlier quoted context omitted.

this sounds like something you can fix with a two-line shell script #!/bin/sh exec /usr/bin/xpra --ssh=ssh "$@"

You're making it way more complicated than it should be. Just edit the defaults in `/etc/xpra/conf.d/40_client.conf`: https://github.com/Xpra-org/xpra/blob/eedf34ecef3a04d0867709... (or your personal defaults in `~/.config/xpra`)

hey, thanks! i'm not sure that makes it less complicated (it means the same xpra command line will work properly on one machine but not another) but it definitely looks like a solution!
Post reply on HN