crschnick @ crschnick @sh.itjust.works

Posts

21

Comments

107

Joined

2 yr. ago

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

I see your points. In the end it boils down to the fact that there is no clear split between free and paid features in the codebase itself due to the chosen commercialization model. The paywall that is in place right now is mostly artificial because the code is the same for all systems. So even if I wanted to, I could not implement the classic open core model with a fully open source base version. I could have used a different approach to start out, e.g. only locking certain features behind a license and not certain remote systems like it is currently done. That would have probably allowed me to implement the more classic open core model. But the current model also has its advantages in other areas.

You can just ship your own version of the repo if you want due to the apache license. To properly run this the user would however still need the regular xpipe installation which contains some parts that you would still need to properly make use of it. I think the term basic core functionality can be interpreted differently here. So if you are talking about being able to use all the nice features that make xpipe stand out, then yes these non-open-source components are necessary for core functionality. If you are just talking about being able to run the application and do limited things with it, then they are not.

Yeah maybe the term open core is not the best way to describe it as it doesn't entirely fit the pattern. I'm open for better suggestions where I can still somehow highlight that most of the application is open source (in terms of LOC, it is around 90% in that repo)

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.

From your description I would say yes.

You always have to fiddle around a bit with SSH jumps and fowards as there are two different ways in xpipe to handle that. You also have to take care of your authentication maybe with agent forwarding etc. if you use keys. But I'm confident that you can make this work with the new custom SSH connections in xpipe as that allows you to do basically anything with SSH.

In summary, there are a few components not included in the public repository, mainly because it is very difficult in practice to get people to pay for a 100% open source tool where they can just clone it and remove any license requirement in a few lines. So it is not a fully Apache licensed application, it's core is. There is only one release version so it is difficult to provide a separate apache-only installer, mainly for technical implementation reasons. Some codebases can't be perfectly split into free and non-free parts that can be shipped separately. These not included components are the license handling implementation, the low-level shell process handling implementation, and the CI/CD scripts for distribution.

The EULA is just standard terms like don't try to circumvent the license requirement, if you buy a license don't share it with other people, some warranty and liability stuff, etc.

If you build a development version from source, it requires to have another xpipe installation present where it can utilize some of the shipped components from it. But you can fully run and modify that development version. They are not necessary for basic core functionality but it doesn't work without it as the license requirement could be disabled easily then as I mentioned before.

Overall I think this split is the best solution considering all factors. I understand that some open-source proponents don't like that. But I think since the application core is open source, it still has the good effect of establishing trust because anyone can take a look at how your data is handled internally, which is especially important in this context where a lot of sensitive information is used.

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.

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.

Essentially yes. You are correct, it is not a service to host. Instead it is a desktop application that works on top of your existing CLI tools.

Thanks for the feedback!

• There is a custom shell functionality under add command -> shell command, however it's not perfect so you have to see whether it works for your cases
• I am not sure whether direnv works when you create a custom shell environment in xpipe with an init script of cd , I can test that
• About connecting to docker containers and other hosts, you can in theory connect as any user. However some parts like an on demand sudo elevation is currently bugged, but will work soon.
• Yeah I can imagine that using it in a tiling window manager is not very pleasant, I honestly did not take these into account when designing it. However, I plan to get rid of separate dialog windows and merge them with the main window.

Oh I see, that went over my head 😀

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.

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

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.

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.

An update: The latest release now has full support for SSH tunnels and I reworked the downloading and transfer process in the file browser.

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

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

That is unfortunate that you had to deal with these bugs. The challenge here is that every setup and shell environment people run this in differs and there was only so much testing I was able to do on my end. Reporting bugs is very helpful to me and they can usually get fixed pretty quickly.