In this case I am trying to market XPipe as a one-man company. Yes, that is technically still a company, but it’s a little bit more personal. Because here you are not talking with the marketing department of XPipe but with the developer of it.
Yeah the pricing model requires the homelab plan for larger Proxmox cluster setups with multiple nodes. However, there are no limits to what you can do with that one Proxmox node. You can fully use every feature with it there is no limit on the amount of VMs you can manage in the community version on that node. Just when your homelab setup is larger and has multiple nodes, it requires the homelab plan. And at the end of the day, I think you can form an informed opinion on whether upgrading to the homelab plan would make sense to you after using the one node for some time. If you don’t think the saved time and effort with XPipe is worth the 5$/month for you, that’s fine. Everyone can determine that for themselves.
Wow, I missed quite a discussion up here when I was away.
I would argue this is part of this community, a showcase and status updates of projects that can be useful for the selfhosted community. I understand that there is a focus for completely free projects in here, but some tools showcased here also include a paid plan. In this case I’m trying to make a living out of this, so there is a payment model in place. I limit my posts to only major updates, so the post frequency is dependent on the development speed.
There is a free community plan available that covers many use cases, there is no need to pay for XPipe unless you want to fully commit to it and use all of its features.
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.
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.
As I mentioned in reply to another comment of yours, the main difference in my opinion here is that I am posting this as an individual one-man company compared to something like Oracle. And the Oracle free tier still requires you to sign-up and provide your data. This free version does not have such a commitment.
A lot of projects are sharing status updates and development news and various platforms, some on lemmy as well. On average, I post status updates every 1-2 months when there is something to share. And yes this is self-serving, I am advertising my project after all.
I think blocking me would be a bit overkill? You could also just downvote the posts you don’t want to see and move on, you don’t have to read my posts if you don’t like them. That is up to everyone themselves. People who are interested in these posts can do the opposite.