There are certainly some similarities, i.e. you use both to connect and work on your remote systems. However, the main difference is that XPipe does not come with integrated connection capabilities or an integrated terminal. Everything is delegated to your tools, i.e. XPipe for example connects via your installed ssh command-client and launches the terminal emulator you choose, nothing is included in the application itself.

On a more fundamental level, XPipe is not aware of any protocols like SSH, SFTP, FTP, and more. Instead, XPipe creates a new process using for example your local ssh executable, which is usually the OpenSSH client. I.e. it launches the process ssh user@host in the background and communicates with the opened remote shell through the stdout, stderr, stdin of the process. From there, it detects what kind of server and environment, e.g. shell type, os, etc. you have logged into with that shell connection, and adjusts how it talks to the remote system from there

As a result of this approach, you can do stuff with XPipe that you can't do with other tools like MobaXterm. One example would be connecting and accessing files on a docker container as there's no real protocol to formally connect here by default. XPipe can simply execute docker exec -i sh to open a shell into the container and handle the file management through this opened shell by sending commands like ls, touch, and more.

More broadly, XPipe can work on any shell connection, regardless of how it is established. From its perspective, there's no visible difference between a remote ssh connection, a shell in a docker container, or your local system shell.

Furthermore, MobaXterm is Windows only while XPipe is cross-platform.

What do you refer to here? The UI or something else? I haven't heard the word gooey being used to describe an application before, but I'm also not a native speaker.

You get a fancy overview over all your remote connections and don't have to type anything to establish shell connections in your terminal, you get launched into the session with one click, so it gives you an overview over your server infrastructure and saves you some typing effort.

Also you can access the file system of any connected remote system via a graphical user interface, but I guess that is personal preference whether you would like to use something like this or not.

Overall, XPipe makes it much less tedious to connect and access remote systems wherever they are located, especially if you have to go through multiple intermediate systems in between. Once you added a system to XPipe, you can just connect to it with your favorite terminal in one click just as you would do manually and also browse the file system. Having a graphical overview over all available remote connections and their file systems can make your life easier, especially if you work with many different remote systems, containers, clusters, and more.

If you just regularly connect to two simple servers via SSH, then you probably won't get that much use out of this. But if you have many servers, gateway servers, containers, and other subsystems running, then it will make your life easier.

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.

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.

It's not really related at all.

It is basically a graphical wrapper around your CLI tools like ssh, docker, kubectl, and more that gives you the features you know from tools like graphical SFTP clients but supports much more types of connections and allows you to use your favourite terminal and editor for your remote connections.

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.

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 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.

• Technically there is loads of proprietary stuff that tools like RealVNC do to increase security, but that cannot be considered the open VNC standard.

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.

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.

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 that is understandable, everyone has a different attitude towards that matter.

Do you use the normal one or the FIPS one? Maybe I can use that to differentiate between personal and commercial use

You can if you're interested in any status updates

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.

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.

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.

You can use it to work with any remote shell connections. I use it for my WSL instances on Windows and Docker containers on my Linux servers to connect to them in my terminal and interact with the file system through the graphical user interface as I prefer managing files that way. Support has also been expanded by request to include things like Kubernetes clusters and their containers.

Overall, XPipe makes it much less tedious to connect and access remote systems wherever they are located, especially if you have to go through multiple intermediate systems in between. Once you added a system to XPipe, you can just connect to it with your favorite terminal in one click and also browse the file system.

Yeah I can do that

Yes

Alright, I will have to look into whether it is possible to differentiate between normal and FIPS here

An update: I was able to reproduce the issue of growing memory usage when frequently adding connections like containers. As long as you don't add more connections continuously in a session, the memory shouldn't really grow that much. So a restart should improve the situation.

That is great to hear! I just happened to very recently add built-in support for more Linux terminals like alacritty, so I hope everything will work here.

I assumed that yubikeys would be found pretty much only in enterprise environments but perhaps I was wrong there.

Maybe I can find a solution to that. The free plan restrictions are not perfect yet and I was planning to experiment with different solutions to it. If you just want to try it out, I can also offer evaluation licenses if you're interested.

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.

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.

That would definitely be possible, although I have no idea on how to do that so I would have to familiarize myself with the process first.

Now I'm not familiar with the details of zerotier, but XPipe does support using other connections as gateways. So if your network is only accessible from the outside through one login/firewall server then you can connect to that server first and use it as a gateway for your second ssh connection to some server inside your network.

This functionality is technically completely separate from the SSH tunneling with port forwarding, but it does suffice in many cases. If you require proper SSH tunneling functionality, then that can for sure be added.

That is unfortunate to hear about these performance issues. Performance was not my main focus initially as optimizations are always supposed to come later on, but I guess that time is now. How many connections do you have added in total? I was not able to reproduce anything getting over 1GB of main memory with like 50 total connections. Also, does restarting fix some of that?

The best way of diagnosing that issue would be a heap dump of the application, but that requires some effort of getting it and also sharing it somehow, but we could do that if you want.

That is good to hear it works at least to some degree now. In theory, xpipe does detect your installed terminals at launch and will select the most appropriate (i.e. prefer iTerm2 over Terminal.app if iTerm2 is installed), however it seems like there are some false positives as is it quite difficult to properly check whether an app is installed somewhere on macOS.

The UI feedback is definitely on my TODO list, having a status bar for example that tells you exactly what is currently going on would be very nice to have instead of just a spinner or nothing at all. I will see what I can do there

Yeah it could definitely show the currently running command, although it will be tricky to not spam the user with too many commands and information in short succession, but we will see.

I guess the main reason for the popularity of iTerm2 is that the normal Terminal.app is just a little bit too basic in terms of its features. It works fine but nowadays people expect a little bit more.

I managed to do that, so you can now try it out at: https://aur.archlinux.org/packages/xpipe. Let me know whether everything works for you there, I was only able to test it on one Manjaro VM.

I managed to do that, so you can now try it out at: https://aur.archlinux.org/packages/xpipe. Let me know whether everything works for you there, I was only able to test it on one Manjaro VM.

Yeah since the last time a lot of aspects were improved, including the GUI performance which was quite bad. I hope it works out now

Oh I see, that went over my head 😀

Yeah I can understand why some people feel that way. Originally this closed part only concerned a very small part, but due to necessary subclassing of that implementation, that kinda evolved to the whole shell handling interface. I always wanted to refactor that aspect and decouple it such that these parts can be included in this repository, but never got around to it.

Maybe in the future this can be properly addressed because it's more a matter of a not well thought out structure rather than hiding crazy secret implementation details. The whole project's vision moved around quite a lot and most stuff was conceptioned before there was even a thought to try to sell it.

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.