![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/q98XK4sKtw.png)
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.
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.
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.