crschnick

Alright I see. With the more professional homelab setups it will be always difficult to properly differentiate all cases for the community and professional edition here.

But you can send me an email at crschnick@xpipe.io, I can provide you with an evaluation license.

It should be close to the CommonMark spec, so it should support the same features as you find e.g. in GitHub markdown.

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.

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.

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.

As a sole developer I have to prioritize features due to the time constraints. While I would definitely like to implement support for everything you listed, this would be a lot of work. For example with terminals in general, it can be very difficult to get one up to the standards of other comparable terminals. By delegating everything to other terminals, I can make the development easier.

So in the long term future this might be added. But that also depends on the project's trajectory going forward

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.

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

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.