crschnick

With the AOT cache, you can actually modify the classpath (or module path as is now used for modern applications) after it has started up. The names and classes for the APIs are different, but you can still load jars at runtime even with the AOT cache enabled and functional.

The AOT cache compatibility issues come when your boot module path differs between training and actual run. As long as that is not the case, you can use it without problem and load additional modules at runtime after it has started up.

With GraalVM, that is not possible. It still has the closed-world assumption.

Ah I see. The reason it complains now is that the LTSC systems are called Windows Enterprise LTSC, didn't even know that they fell under the Windows Enterprise category.

You can run XPipe on a local LTSC installation, you just can't connect to one remotely because it thinks that you are connecting to a Windows Enterprise server. I will think about how to solve this the best way, because that wasn't on my radar

Yeah I remember that some time ago there was an attempt to make it run on BSD by some BSD users, but that didn't work out as some dependencies like the latest JavaFX version was not available for BSD yet. That is one of the disadvantages when always switching to the latest versions

There isn't good support for nested RDP connections, didn't even know that some people used something like this.

But there is very good support for nested shell connections and tunneling RDP over SSH. If your target system isn't reachable directly and require something like a bastion host connection first, you can still connect via RDP if you use SSH tunnels over multiple hops in XPipe.

- When XPipe will open a terminal connection and you have specified custom shell environments / init scripts for a certain system, it will first automatically create a temporary init script on the target system in the background, which will be run as the login script only for that terminal launch from XPipe. That way it's noninvasive and doesn't change any existing configuration on the system

- XPipe acts as an askpass program for SSH, meaning that it can listen to any password requests made from the ssh client, forward that your password manager, and reply with the password that the password manager returned. If you password manager supports the SSH-agent, XPipe can also use it to supply keys for ssh as well.

The current KVM integration is actually more formally an integration for libvirt and the virsh command-line tool.

If your hypervisor is supported by libvirt, you should already be able to use it in XPipe.

If it does not support libvirt, then I guess this would need a separate integration. But I would have to look into that first as I have never used these tools you listed.

Interesting, haven't heard of that before. That is not supported right now, but I can look into it. It also depends how good their CLI works for me to integrate it

On macOS there are still a few reliability problems, mostly caused by misbehaving zsh extensions that I have to work around. I replied to your issue report, I think this should be fixable.

There's only one release build which contains all feature implementations, but some of them are locked behind the plans. So to some degree, they are artificial as there isn't currently a separate build for the Homelab and Professional builds.

The only service it relies upon is the licensing server, but if you also don't want to use that to be fully independent, you can request an offline license. You can find the details about that on the pricing page.

Right now, there's no direct import from WinSCP, next best thing where it can import from is Putty

Are you using the LTSC version on your desktop or also for some of your remote systems? I think if it's only for the desktop, I can fix that as that isn't really intended to be limited to the Professional version. Didn't really test it on an LTSC system so far, so I will look into that

Yeah, I think something like that will be properly supported once I get around to implementing an aws integration in the future

That is true, but ideally with XPipe you can do that easier and faster. And with the time and effort you save each month, the few $ per month can be good deal for you.

Now I don't fully know the details of your setup, but in general XPipe just works on top of your kubectl installation. So it will only work if you could manually connect to your clusters via kubectl in a terminal. But you can always just try it out and see what happens the community version because I can't say that for sure.