crschnick

I fully get that. The reason why it focuses on the subscription model is that is quite difficult to plan ahead with an irregular revenue stream. Everything is financed via bootstrapping, so I can't afford to burn through money or have irregular revenue over time when planning expenses.

Yeah feel free to open a feature request on GitHub, that way I can keep track easier. You can also make my life much easier if you provide more details on how exactly such an integration could work. Because in practice, many requested integrations are for tools that I have never used before. I have to first figure them out myself and set up proper a testing environment. That part sometimes takes more time than implementing the actual integration itself because some tools are quite difficult to set up (Looking at you, goteleport).

You will own a lifetime license for the software if you choose the lifetime plan.

Everyone has seen it in practice that some companies try to pull a bait and switch by then changing the terms of licenses or simply shutting down the servers when going out of business. Since this is a desktop tool not hosted on any server infrastructure, at least the latter part isn't that much of a risk. You still have to have some trust in me to honor the license terms, but I try my best to build that trust.

There is also an offline license functionality, meaning that if you obtain a lifetime license and request an offline license file, that one will not perform any verification with any online services, so it will work forever without any dependency on some SaaS infra. Anyone interested in that can simply request an offline license, you can find the details on the pricing page. The offline licenses are also often used for usage in air-gapped environments.

Yeah things like Okta are planned to be supported in the long term. Just need to prioritize the different integrations as there are so much tools I can still add support for. And every single integration presents its unique challenges, so these all take some time.

The idea behind that is that people usually don't run RHEL for fun, there is mostly a business need for that. Especially since there are distros like Alma Linux out there, which you can use with XPipe for free.

Alright that is good feedback. I haven't actually thought about this, but it would also make sense when a user updates their config hosts in general. There is a refresh button for the config, but that one also does not reload everything. I will definitely improve that.

About the reimport, you can right-click the SSH config root, remove it, click on the magnifying glass button on the local machine to automatically add it again with the latest info. But I can fully understand that you don't want to do that, dealing with unintuitive interfaces isn't fun.

You can go to Settings -> Synchronization and enable the remote git repository sync. If your team members synchronize with the same remote repository, this should effectively allow for a team collaboration.

I think it's good to be aware that there is a lot of bad tutorials/libraries for JavaFX out there. Also many StackOverflow answers are quite outdated as the popularity hit a peak like a decade ago. Also don't use FXML (the weird declarative way of creating GUIs).

I think the best way to get started would be to download the sampler application from https://github.com/mkpaz/atlantafx. That is state of the art, good implementation. You can play around with it and jump to the source code to see how it is implemented. It contains almost everything an application needs.

Also depending how old your general Java knowledge is, the modern way of creating applications is through the module system and the jlink/jpackage tools. There are many outdated solutions for application packaging out there as well. If anything you see is using the classpath, builds jars or fat jars, or is using external tools outside the JDK, it's probably old and no longer appropriate.

If you want to keep using emacs, there is the possibility to launch any custom editor in xpipe via a command. You could use emacs as your primary editor with it.

Thanks for your feedback. To answer your questions:

3. Making the source available would technically be possible, but I would have to consult with a lawyer for that first on how such a thing would be implemented. But I can definitely see this being a feature for the enterprise plan if the customer is interested in it.

4. XPipe uses JavaFX as the GUI framework. It might not be the most fancy and modern solution out there but gets the job done. It is still maintained, but that concerns mainly bug and security fixes. In terms of new features there isn't that much happening but that's not that bad as the desktop hasn't changed a lot over the last decade. There might be more modern solutions out there like Jetbrains Compose, but the advantage of JavaFX is that it is very stable and mature. There's also a good ecosystem of libraries for it.

5. In terms of license enforcement, it's pretty lenient. You only have to validate the license after at most 7 days, so if you are offline for a period of time it will work fine. If you are working on a fully offline system, there is also the possibility to request an offline license that will not require any internet connectivity. See https://xpipe.io/pricing#faq for that.

6. I try to do my best shipping a stable product. I think most developers would probably want to do that, but in practice it's usually investors or management pushing down from above to get features out quicker. I guess I'm in the fortunate position right now being able to choose my own development pace.

I'm not deeply familiar with the vscode internals but figured that they were doing something similar as many issues and error messages that were thrown by shells and various programs led me to some vscode issue with the same problem many times.

Because it turns out in practice some shells and programs do not like being run in the background in a dumb terminal as this is an obscure use case.

Well it is open-core on GitHub right now. I think full open source is going to be difficult if you're trying to sell it. At least in the desktop application space with no account setup or other service dependency it's complicated as anyone could circumvent paying by cloning it and commenting out a few lines.

But I can fully understand your concerns, establishing trust is important. At the end of the day it's up to you whether you feel comfortable enough with it.

On a fundamental level, the difference is that winscp is based on certain protocols like SFTP and ships their own SSH implementation for that. XPipe uses your existing ssh CLI client to accomplish the same thing instead. This makes it more flexible as it integrates with your SSH local config out of the box. This also allows you to use any arbitrary terminal emulator to open connections, in contrast to WinSCP.

But there's also much more included in XPipe that you can't find in WinSCP. There is SSH tunnel support, container support like for docker, dynamic root elevation in a file browser session without having to restart, a scripting system, a VNC viewer, an RDP launcher, and more.

Interesting, have not heard of that before. But yes, it is definitely similar in some aspects to that.

I pushed an update that fixes this issue on macOS.

It seems like someone at apple thought that having mdfind always return 0 even if I didn't find anything was a good idea.

So I released an update that should hopefully fix / tweak this behavior.

I think to apply you would need to remove the config entry in xpipe and search for it again.

It supports creating and enabling SSH tunnels to forwards ports, i.e. local, remote, and dynamic port forwarding.

Oh that seems like a bug on my end, on macOS it seems to default to kitty as your terminal application even if it is not installed.

You should be able to fix this by going to Settings -> Terminal -> Set the terminal emulator you want to use

I guess that depends on what you mean by synchronizing here. Right now it can access and manage the raw docker containers on remote systems. There isn't special support for docker compose, but that is one possible thing I can add in the future.

The indentation shouldn't really matter, I will try to figure out what went wrong there.

If you are looking for key points from the perspective of a heavy ssh CLI user, you can think of it as a fancy wrapper around your existing SSH client and configuration.It will automatically detect your SSH config and supports exactly the same set of features and options as your SSH client as it internally uses that one. It doesn't try to replace your existing SSH client and configuration, it works with it.

What it will add:

- You have direct access to all systems running on the servers you connect to, e.g. docker containers, using the exact same graphical interface. On the CLI you also have that in theory, but that's tedious

- You can bring your shell environments / init scripts / aliases with you in a noninvasive way. I.e. you don't have to modify the remote system dotfiles, when you connect through xpipe it will set up any scripts you want to have available automatically

- You can link up your password manager with your SSH client and other connection methods that require passwords

- You have the ability to synchronize your connections and environments through git, including your SSH configs

- You get special integration for SSH tunnels that allows you to toggle them to start / stop in the background, you can also make tunnels automatically start on XPipe's launch

- You get an overview over all your remote connections and can access the file system of any connected remote system via a uniform graphical user interface

Thanks for trying it out and describing your issue. I assume that you mean that you have the IdentityFile option configured for every connection in your config file?

That should work though, it might not list the file as an explicit detected key-based authentication method when you edit the connection (Might be listed as None), but it should still apply the identity file option you have set in the config.

If that is not happening, then this is a bug and I can investigate that.

The original idea was that since the systems you listed usually cost quite a bit of money to run, these would primarily be run in an enterprise context. I don't think I could afford hosting a managed kubernetes cluster and multiple decent servers in Amazon or Azure for personal use.

The Yubikey security argument is fair though, I will reconsider that.

The number of machines detection has been on my TODO list for a while, but it's a little bit tricky to implement with the current implementation.

Yeah the Proxmox limitation originally came about because I didn't find a reliable way to detect enterprise use from the CLI (But I had not used Proxmox before implementing that, so I might have missed it).

But if I see this correctly, I could call the API from the command-line with this: https://pve.proxmox.com/wiki/Proxmox_VE_API#Using_'pvesh'_to... and check the response. If that is possible I can definitely change that limitation.

As someone unfamiliar with that emacs term (more of a vim user), you had me confused for a moment there.

But after reading up on that, it is actually quite similar to what xpipe does. Good to know about, I will dig deeper into it and see what the emacs community came up with.

Alright thanks for the feedback on the yubikey. 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.

I think as the developer I can comment on this since I initially built it for my own usage.

The main goal of project is to enable easy file system and terminal access to all your servers, including things like docker/podman containers, k8s clusters, and more that you normally can't connect to with existing solutions out of the box.

It comes with a file manager that is built specifically for remote systems and their workflows, so it doesn't try to rival any local file managers like Windows Explorer.

xpipe dev here, that is definitely possible. The main limitation at the end of the day is the development time, but I'm confident that eventually it can branch out to support more tools and technologies.

So stay tuned for that