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.

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.

Thanks for your video showcase back then, it really helped the project get the initial traction.

The project was definitely rough around the edges back then. It held together somewhat but I would say it was around a 50/50 chance that it would work as expected for a new user. I think that has been the biggest improvement since then, the reliability and handling of edge cases so that the vast majority of users can now use it as they expect without issues. That was made possible with the help of the community which reported and tested all kinds of things I could not have done on my own. Having a community running a diverse set of systems helps out development immensely.

That is great to hear!

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

Yes

That is great to hear!

For MobaXTerm you can always try to ask the devs to maybe expose the functionality to launch their terminal from the command-line. That would work.

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

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

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.

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.

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

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.

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)

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.