process-compose VS xrdp

The IMO superior https://github.com/F1bonacc1/process-compose project has this built in, while allowing to manage regular programs that don't require containers.

See:

Devbox can also run services too. Both products use an awesome process runner called process-compose (https://github.com/f1bonacc1/process-compose/) which is worth checking out (it's even built with nix!)

I've been using https://github.com/F1bonacc1/process-compose with great success.

It's a userspace process compositor that works across all relevant platforms, supporting daemon processes and k8s style readiness/health checks.

In combination with nix flakes, it quickly reduced my projects docker-compose usage for easy-to-configure services.

This gave huge performance benefits for the M1 Mac folks on my team especially for CPU intensive processes thanks to native binaries.

For maximal ease of use, the remaining docker-compose containers are started/stopped as a process-compose task.

In order to run a simple client-server (1 client, 5 servers) application, I wrote a simple docker-compose file and everything worked great. My dev flow would be the usual: make some changes/optimizations, spin everything up, run a bunch of tests, and go back to step one. At some point, I felt that for my dev environment and language (Linux, golang). docker-compose is great for spinning everything up, but for rapid development, it actually slows me down. I didn't really need containers. I tried to find an alternative solution. Something like a docker-compose, but for native processes, but most of the tools that I found were CI/CD oriented. I like K9S (who doesn't?) and I like docker-compose (some don't), so I built a Frankenstein Monster of them both :) https://github.com/F1bonacc1/process-compose I am not sure if you'll find it as useful as I do, but in any case, any feedback is more than welcome.

xrdp

Or maybe it could be done through xrdp somehow?

Part of the reason that RDP isn't better is because it's not an open protocol, part of the reason is because the protocol was built to present a desktop environment that isn't remotely like xorg or Wayland. A lot of the reason is that the RDP project just doesn't get enough effort, because people have multiple ways of sharing desktops, and RDP is just one of them. If you would like to fix that, here's the (currently) 274 open bugs against the Linux attempt to implement RDP https://github.com/neutrinolabs/xrdp/issues

Check out xrdp. You can connect then via any rdp client.

If you're willing to compile there are patches to xrdp to include some performance improvements that make a huge difference (more modern codecs). Tracking issue with instructions is here https://github.com/neutrinolabs/xrdp/issues/1422 it's quite long, so I'd start reading closer to the bottom. Performance has been really good in my testing.

This may help. https://github.com/neutrinolabs/xrdp/issues/2034

Indeed, this was... 2002? or so (xrdp)[http://www.xrdp.org/] was still not available.

So... just use Remote Desktop. A popular open source version of RDP is XRDP, which is packaged and available for installation on most popular distributions. Just install it, let it start up the xrdp service, and then connect to it just like it was a Windows server. That's it.