crschnick

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.

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.

Yeah the commercialization model is not perfect yet. Ideally the community edition should include all normal features required for personal use. Would that only be like one machine to connect to or many? I was planning to experiment with allowing a few connections where a license would be required in the community version.

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.