search

jupyterhub / jupyter-remote-desktop-proxy

Run a Linux Desktop on a JupyterHub
BSD 3-Clause "New" or "Revised" License
116 stars 106 forks source link

Define VNC servers to support #56

Closed consideRatio closed 4 months ago

consideRatio commented 1 year ago

This project ships with TigerVNC, but has support for use with TurboVNC as well, and really any vncserver binary:

If a vncserver executable is found in PATH it will be used, otherwise a bundled TightVNC server is run. You can use this to install vncserver with support for other features, for example the Dockerfile in this repository installs TurboVNC for improved OpenGL support.

Should we aim for something simpler to reduce complexity and ensure robustness on what we really can manage to test and maintain? I'm thinking that we could remove TigerVNC for example.

Related

benz0li commented 1 year ago

The bundled TigerVNC is x86_64 only.

Debian/Ubuntu has packages for both x86_64 and AArch64

yuvipanda commented 1 year ago

I actually think we should just stop bundling a VNC server completely, and just require it be installed separately. This also solves the licensing issue.

consideRatio commented 1 year ago

I'd like to reach consensus on a path forward among us who have involved in thinking about this so far @cmd-ntrf @benz0li @yuvipanda.

Related

Answer template

> **Question 1: Do we stop bundling TigerVNC?**

> **Question 2: Do we provide install scripts for TigerVNC and/or TurboVNC?**

> **Question 3: Do we commit to testing TigerVNC and/or TurboVNC?**
consideRatio commented 1 year ago

Question 1: Do we stop bundling TigerVNC?

Yes, its x86_64 specific and it has a licence we are breaking.

Question 2: Do we provide install scripts for TigerVNC and/or TurboVNC?

No, I don't think we should. If we do, we should have it for all the VNC clients we support. My motivation for not suggesting we introduce this is because of the maintenance burden we take on in this project that currently doesn't have tests setup. If we have tests setup, I'm open to re-evaluating this answer.

Question 3: Do we commit to testing TigerVNC and/or TurboVNC?

To me, this is the same as "Do we commit to supporting TigerVNC and/or TurboVNC". I'm open to supporting / testing both and, or just picking TurboVNC - but I'm hesitant to only pick TigerVNC based on what I've understood so far.

benz0li commented 1 year ago

I agree with @consideRatio's answers.

consideRatio commented 4 months ago

We now have tests for turbovnc and tigervnc and its far more clear now, closing as resolved!