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.

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.

Yeah there is always the JVM overhead which is unavoidable here. That, plus all the images which are preloaded into memory to reduce any loading time at runtime, sum up to that base amount of RAM being used.

Yes, that is how it is intended to be used. Assuming that you can easily connect to your server via something like SSH, you should have access to all docker containers running on it.

I see you edited your original comment since last time, so I can augment my answer.

I could definitely include a lifetime purchase option for a certain price, but I was skeptical whether people would actually be interested in something like that, mainly due to the potential price difference. I honestly thought that the current model would be better received by potential customers as it is more a pay only what you use model while also keeping access. I did not expect that anyone would actually be interested in a lifetime license. But to be fair, the payment model was designed back when the application was in an earlier development stage and didn’t even work properly for like 50% of users.

I will definitely rework the website to better get the point across on how continuous updates are handled as there is no intention to make it a predatory model. Then I will reevaluate the licensing model.

Maybe I have to improve the wording on that, you are right.

The idea is based on the established model of other applications, where you buy a license for a certain version. If a new major version releases in that case, you will probably not access to that with your old license. Even if you are perfectly happy with the version you bought, the issue of that model is that you will also miss out on important bug fixes , security patches, and normally free enhancements as older versions are no longer supported.

XPipe tries to find a compromise here. There is the same build for everyone, which is receiving continuous updates and support. The are no hard version barriers, it’s a continuous development. The licensing system paywall is therefore very artificial in that the build contains all features but it will not allow for usage of professional-only features released after more than one year after your license date. You can keep using all professional features that were included before forever. The important part is that you will still receive updates as anyone else, you just can’t use new professional-only features that are included in them if more than one year has passed. But you will receive bug fixes and security updates even if you own an ancient license.

It uses the sudo credentials from the SSH connection, even if you don’t need to provide a password to login. So if you set a password for a SSH connection, it should use that for the sudo elevation.

You can send me feature requests either on GitHub, Discord, or mail, whatever you like.

Your proposed enhancements make sense, I can already think about how to add this the best way. And if you want to open a proper feature request and elaborate more on that, we can make that happen for sure.

As a sole developer I have to prioritize features due to the time constraints. While I would definitely like to implement support for everything you listed, this would be a lot of work. For example with terminals in general, it can be very difficult to get one up to the standards of other comparable terminals. By delegating everything to other terminals, I can make the development easier.

So in the long term future this might be added. But that also depends on the project’s trajectory going forward

Alright that is understandable, everyone has a different attitude towards that matter.

The screenshots are just sample connections, you can connect to arbitrary systems via SSH so it is not really a tool intended specifically for AWS.

Obviously if you are using taylor made tools for AWS by amazon itself, XPipe can probably not compete with that in terms of features. This is more of a general purpose application that you can use with any servers, virtual machines, containers, and more.

It verifies whether it can actually connect to a system prior mainly because you have to do it anyways at one point and also to query system information to for example display the operating system name and logos. What exactly do you mean by on the fly here? Maybe I can improve the flow for use cases like yours, I personally have never dealt with keys in password managers.