Nope, an application like this can’t work as a flatpak as the sandbox prevents almost all shell functionality and makes the application unusable. Yes, the AppImages are basically the best solution for immutable operating systems.

I think in the end you still have to exercise some trust. There are things like audits, but these are costly and not an option in the current stage. Maybe in the future. Best I can do is to provide transparency by open-sourcing large parts of the codebase and providing detailed security information like https://docs.xpipe.io/reference/security.

As someone who sometimes sells to the german public sector, it is true that they would prefer a good open source solution if it was available. But me being a german vendor makes up for it, as they still prefer this a lot more over any US-based vendors.

In general about the key handling, XPipe doesn’t read any kind of keys itself, it only forwards them to the local OpenSSH client. It is essentially a wrapper around in existing ssh client, and doesn’t implement anything related to key handling itself.

I think if you have a specialized tools with openstack, XPipe probably can’t compete with that in that area. But it can make your life easier in a lot of other areas and common tasks when it comes to accessing many servers.

About the FOSS requirement, I know that this is a dealbreaker for some. That is a tradeoff when going the commercial route

Alright, feel free to let me know how it compares to your other tools that you use. That is always a valuable insight for me

Yes, you can use any local editor to edit your remote files

How large is your homelab cluster? The current restriction of only one Proxmox node is mainly there because in practice I don’t think it would be possible to distinguish between personal use and commercial use. Because many companies also run a cluster with multiple nodes without the enterprise repository as that is not really needed.

The display issue is interesting because I was not aware of that before. I have a few Linux systems with a gnome DE, but none of these are using nvidia hardware acceleration. I can definitely look into finding the cause for this if you want, but it’s only really worth it for you to spend some time on this if you actually want to keep using XPipe. If the current restrictions are a dealbreaker for you, then I understand that.

I think a screenshot of how exactly it looks for you would already be a good starting point for me.

I guess that depends on what you consider basic homelab functions. As I mentioned, I know that that any commercialization model is not going to be perfect but I try to allow for as much free usage as reasonably possible.

About the text scaling, I will have to look into that. I know that some desktop environments are weird with their display scaling and that it is not getting rendered properly there.

The script was created initially because a surprising amount of users were a little bit overwhelmed with manually installing a .deb or .rpm file. I guess with package manages nowadays, you don’t handle raw files that often anymore.

I will see what I can do about submitting it to package managers.

Yeah I guess I haven’t really accounted for these atomic versions, so I don’t think the install script would have worked.

I might have to try out fedora atomic myself one day.

I think most of the users have something like VNC set up, I’m not sure how widespread moonlight is in the server space. Anyone who comes across this question, feel free to tell me whether moonlight can be considered for server administration.

Perhaps you are thinking of MobaXTerm?

X11 forwarding is as secure as your SSH connection as everything is handled over that as long as you trust the system you connect to as it can send some X11 commands to the client. VNC by itself is insecure but XPipe tunnels all VNC connections via SSH as well, so it is secured as well. With RDP, I would argue that there are less sophisticated authentication options available for RDP than for SSH.

I think moonlight and sunshine are intended for gaming while this more intended for server administration tasks.

Sadly this is not possible due to the flatpatk sandbox, at least without having to rewrite basically the entire application. You can’t open other applications or shells from the sandbox, so nothing would work. Someone told me that it is possible in theory to reduce the level isolation of the sandbox via flatseal, but that would require the user to perform additional operations to make it even work. If it is not going to work out of the box, a flatpak version would not make a lot of sense.

There is an optional automatic update check included that will notify you when a new version is available. You can also automatically install the new version through that, but that is up to you.

For NX, I assume you’re talking about this: https://www.nomachine.com/. I would have to look into that, it depends on how open the protocol and platform is. Without looking too much into it, I would assume it has some basic open component but since there is a company involved, there’s probably some proprietary vendor lock in. It’s probably the same as with VNC where there is an open protocol spec, but RealVNC also develops their own closed spec to lock out any third party clients from interacting with their tools.