Thanks for your video showcase back then, it really helped the project get the initial traction.
The project was definitely rough around the edges back then. It held together somewhat but I would say it was around a 50/50 chance that it would work as expected for a new user. I think that has been the biggest improvement since then, the reliability and handling of edge cases so that the vast majority of users can now use it as they expect without issues. That was made possible with the help of the community which reported and tested all kinds of things I could not have done on my own. Having a community running a diverse set of systems helps out development immensely.
In terms of any authentication, XPipe doesn’t implement anything by itself. It will just delegates to your local SSH client. If you can set that up with your ssh client so that you can successfully connect from the command line, it should also work in XPipe.
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.
You can if you’re interested in any status updates
Yeah I can do that
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.
Yeah I did not downvote you, feel free to take a dive into the data if you really care about that.
I think your analogy about the cars can be augmented a bit. I would say that individual components like VNC are not really a car to begin with. VNC is an insecure protocol by default. Technically there are VNC security measures to potentially encode the data, but these are often not used*. Furthermore, even if you encrypt the data stream, VNC authentication options are severely limited. So something like VNC needs to run over something like a SSH tunnel to be considered properly secure. And to properly do that, you need an SSH integration as well. That is one example where these synergies happen in XPipe.
And not to only aggregate them in one view but to also make them interact with each other. It’s not just about having SSH connections, docker containers, or VNC connections side by side, but using them together. For example, any VNC connection in XPipe is automatically tunneled over SSH, so you don’t even need to expose the port. If you add a system in XPipe via SSH, you will automatically have access to a VNC connection as well if a VNC server is running on it. Doing all of that manually is definitely possible, but will take you some time to set up and start each time.
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.
It is a frontend for standard CLI tools yes, but it comes with many additional features. The focus is especially on integrating standard CLI tools with your desktop environment and other applications that you use like editors or terminals.
For example, of course you can just use the ssh CLI to connect to your server and edit files. But with XPipe you can do the same thing but more comfortably. You can source passwords from your local password manager CLI, automatically launch terminals with the SSH session, edit remote files with your locally installed text editor, and more.
Of course you can do this also with tools like putty, but the difference here is the integration. Other tools ship their own SSH client with its own capabilities, features, and limitations. They also have their own terminal. XPipe preserves full compatibility with your local SSH client and terminal. E.g. all your configuration options are properly applied, your configs are automatically sourced, any advanced authentication features like gpg keys, smartcards, etc. work out of the box.
The same approach is also used for the integrations for docker, podman, LXD, and more, so you can use it for a large variety of use cases.
Yeah it is similar to Remote Desktop Manger or Royal TSX but also tries to go a different way in many aspects. The goal of managing your servers is the same, but how it is effectively accomplished differs significantly.
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.
Can you elaborate on what you mean by your problem with opening multiple terminal windows? I am not aware of such an issue, so maybe you can report it on GitHub with a few more details
Alright, the pricing options and website have been updated. It should now get the point better across about how updates are handled and what you actually get. The fundamental approach has not changed but it should make less of a predatory first impression.
There’s also a lifetime option now, which you can find in the pricing FAQ. It is not put into the spotlight because I think showing very expensive options is a bad business decision, especially when it comes to first impressions.
Yes, the developer can choose a few sandbox permissions, however these options are limited. Even if I grant all permissions, I still can’t spawn a bash process from my flatpak application. Flatseal can grant additional sandbox permissions to allow that, but these options are not exposed for the developer.
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.
This refers to having an enterprise license for Windows. If you have such a Windows product key enabled, the OS name will show as Windows Enterprise or as Windows Datacenter.
The goal is to just separate the users into personal and commercial customers, because you would have to spend quite a bit of money for these Windows licenses and keeping such systems running.
But in practice, you can just attempt to connect to any system from XPipe and it will tell you whether if you need a license for that.