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.

Your link is about a completely separate feature, called the AOT code cache (targeted for JDK28, not released yet). The post is about the AOT cache, which forms the foundation for this feature, but is separate and already available since JDK24. The JEP for the feature the post is about is https://openjdk.org/jeps/483

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.

Whoops, it seems like some links were not updated yet. That should be just https://docs.xpipe.io/cli

To preface that, the CLI is only very basic. The only real thing you can do with it is launch shell connections. For more advanced usage without the GUI, there is for example the Python API: https://docs.xpipe.io/guide/python-api

I think everyone cares about updates to some degree. Doesn't have to be about big feature updates, just continuous fixes for various small bugs and performance improvements can improve you user experience quite a bit.

If you used XPipe a year ago, it's night and day compared to today in terms of features, stability, and performance.

If you're looking for security details, you can find them at https://docs.xpipe.io/reference/security

Considering the costs of a more serious homelab, I think paying $5 a month for a tool that can save you some time and effort, can be reasonable. Of course only if you see the value for yourself. That value comes from more features than just the shell opener, that is only a part of XPipe.

The community version is pretty extensive in what you can do with it, so I think you can accurately judge whether the homelab plan is worth it for you by using it for a bit.

On the pricing page, you can find a feature matrix. The advanced SSH features are basically things like smartcard support, custom Pkcs#11 libraries, etc.

The goal of XPipe is to be connection hub that brings together your tools, not really replace them. For example with RDP and remmina, XPipe has an integration for remmina to launch RDP connections directly, making it easier for you to quickly boot into RDP sessions. Especially when you combine it with the automatic SSH tunneling functionality for RDP that is also included.

For VNC, as the a landscape of tools to integrate is a little bit less populated compared to RDP, XPipe has a built-in VNC client. However, if you still want to use your own VNC client, you can do so using the service tunnel functionality.

What os are you using?

And about adversity to subscriptions, note that you can also obtain lifetime licenses further down the pricing page.

Not yet. But it is definitely on my roadmap for the future to provide an integration for aws in general, maybe also including SSM

Note that there are also lifetime plans available later down the pricing page.

Alright, fair point. I will change that on the website, you can still write me an email to request that

So far I'm happy with the choice. The ecosystem is mature, the build tools (maven/gradle) are solid to build this more complicated project, JavaFX works well enough to realize cross-platform applications, and the performance with modern JIT compilation from GraalVM is good. Currently I'm not missing something important from the tech stack.

Next week, when JDK 24 is released for the general availability, I plan to immediately switch to that as there will be additional performance gains with Project Leyden's AOT compilation and Project Liliput's memory improvements. So I'm positive for the future.

Great that it works for you. I also struggled a lot with setting up various different types of tunnels initially, especially more complex ones. That was one of the motivations why I started developing it.

That is implemented under the assumption that these distros are most of the time used in enterprise contexts. I know that this is not always the case, there is the option to upgrade to a license at no cost to the next tier if you’re only using it for personal use. Just send me an email I can upgrade it for you.

Thanks! Yes, you can find lifetime licenses on the pricing page further down. A perpetual fallback license model like jetbrains has does not exist yet. But I could look into this in the future.

It's cool to see that there are also other people in that space. And about the complexity, I definitely know what you mean. It took a long while before this approach even worked and also took a while until it was actually stable. One of the main points of consideration whenever I think of adding something is the added complexity, because it's very important for me to keep that as low as possible. Otherwise I will end up with an unmaintainable workload. There were definitely a few interesting features I discarded to keep the application as lean as possible.

Thanks, that means a lot to a full stack developer like me

Can you elaborate on that? Then I can better respond to your specific points on why it shouldn't be used