Replace VNC viewer with X forwarding

[sameer-s]

Having the VNC viewer be the primary way of interacting with the Docker container is a pain for multiple reasons:

1. It generally confuses students
2. The clipboard is difficult to deal with
3. It is simply less convenient than having dedicated images
4. It adds a lot of cruft to the container image

An easier approach would be having students install an X server (if on Windows or Mac) and having the container forward the windows to their X server of choice. This would solve pretty much all of the above issues.

As a proof of concept, I've had success running a slightly modified version of the container using Podman and Toolbox, which takes care of forwarding my Wayland ports (can also work with X) and mounting my home directory within the container.

[kanwren]

If X-forwarding is desired, we'd have to pick a specific X server for Windows. Do you know anything about which might be the most suitable?

[sameer-s]

The only one I've ever used is VcXsrv, which worked fine for me (with WSL 2). I've heard good things about MobaXterm, which is like an X server combined with a terminal which is nice since it gives students just one place to go, at least for Windows users.

I think we would also need to use something like XQuartz to get it to work on a Mac.

Caleb also said that he personally likes having it all in the web browser, I don't know if there are students who are in the same boat but as an aside, it might be best to leave that as an option.

[kanwren]

I'll throw together a proof of concept on Windows. In the meantime, can you take a look at the documentation, and evaluate

1. The best way to present the new workflow to students, especially if you also want to keep the old one
2. In light of the additional documentation, new things to install, and workflow, whether following through with it is a good idea?

[sameer-s]

Yes, will do

[sameer-s]

If we were to maintain the existing workflow and add X forwarding, I would probably add it as an addendum to what already exists (i.e., "for advanced users...") since it needs strictly more things than the VNC setup needs (since everyone has a browser).

That new section would basically say:

1. Install an X server (VcXsrv or equivalent for Windows, XQuartz for Mac, either nothing or XWayland for Linux)
2. Remind them to launch the X server before launching apps
3. Show them how to run an application. My recommendation would be to have them set up or download shortcuts/.command files/.desktop files that call cs2110docker with specific flags that make it run the app "locally" when you double-click the shortcut

I think we could probably pull that off without increasing image size very much, if at all. I'm going to speak with Caleb/Shawn/Todd/whoever else cares about whether or not they think that would be valuable.

[sameer-s]

Adding the new option also adds some more hassle down the line though, for instance in PDFs when we talk about the copy-paste stuff.

My personal preference would be to move away from VNC entirely, partially because it's frustrating to use (in my opinion) and students don't seem to like it, and also because we could remove a lot of fluff from the container (xfce and NoVNC)

[kanwren]

I tried MobaXterm on Windows this morning. The experience was relatively smooth. Here's what I did:

• Downloaded MobaXterm through chocolatey, worked without an issue
  • Downloading from the site would almost certainly be equally as easy
  • Note that MobaXterm includes a built-in terminal, so users wouldn't necessarily have to get bash or anything
• Start a local terminal
  • MobaXterm reports the correct DISPLAY setting in a banner at the top, which contains the IP of your computer
    • This is particularly annoying, since it is likely to change, and I can't think of a reliable way to automagically parse the correct IP to set DISPLAY in the Docker container correctly.
    • Note however that with Docker Toolbox, users had to copy-paste the IP anyway (and I think they still do, even though in practice it's always localhost now); having to copy-paste the DISPLAY value as an argument to ./cs2110docker.sh wouldn't be any more inconvenient than that.
• Started the Docker container locally normally with ./cs2110docker.sh -it and exported DISPLAY

From a brief test, all of the normal apps worked just fine.

[kanwren]

I would love to ditch VNC; maintaining it has started to get annoying, and it also contributes to image size directly and indirectly. At some point in the future, I would also like to move to a much smaller base image than Ubuntu, and this would help towards that goal by helping to remove a lot of the cruft that would be likely to break in the process.

Some notes off the top of my head:

• Ditching VNC means rewriting many parts of the script, -it should be the default, and I'm not sure if we should --rm on -it anymore if that happens.
• By word of mouth, MobaXterm has great compatibility. I would need several users across several Macs to test and find what the best client is
• We would need to maintain 3+ separate sets of instructions on how to X-forward! It would be more difficult for students to get help from their peers if they have an issue, and possibly more for the TAs to keep track of
  • The instructions on Linux are also very different from the instructions on Windows/Mac
• Ideally I'd like to switch our mounting setup too; it would be nice to just mount the whole home directory, not sure if this would cause any issues on Windows or Mac.
• Need to set up a plan for the migration
  • What should we do if it doesn't work for a student? Should we keep VNC for a while? (probably just pinning an old version of the container on a per-student basis is best)

[TricksterGuy]

So random comment from outsider. I was discussing with Shawn about this and if this is so much work to maintain, why have it?

I think it would be easier for y'all to just keep the Terminal version of docker and restrict use to running local autograders and just compiling C programs (both vanilla and GBA).

From that Roigisim is java so cross platform and mgba is as well.

I would gladly speed up development of cross platform complx if yall dropped the noVNC thing. It gives me a headache supporting it and I'm doing this for free, I don't enjoy being burdened by this at all.

And yes I get the negative part about such an idea is the burden of students installing software on their own, but I believe its better than this. Docker doesn't seem to be at all good at GUIs in a nice crossplatform manner.

[sameer-s]

I'm curious to see where Nicole stands on this, I personally see no reason to go forward with X forwarding if we can get working cross-platform builds of all the GUI software we have. It's less confusing for students and requires less effort to maintain.

[TricksterGuy]

So it would be nice to get a response to this soon as I have the entirety of next week of which I could dump into cross platform complx. Note that nin10kit is already cross platform so no work needed there :)

A history lesson, when I TA'd the course we used VMs, but we didn't throw ALL of the software on a VM, (which is my first issue with how previous TAs set all of this up). The first 6 or so weeks of the course the students used Logisim on their host computer. We had them install VMWare/Virtualbox/Parallels or Dual Booting (and LUG@GT helped with that) around the 6 week point, but they could do it earlier, for a lab grade.

The rest of the software had to be downloaded onto the VM and there were instructions.

I don't even think you would even need the local autograders for the first few assignments since all of this works via submitting to Gradescope yeah? You could probably stretch that to the first GBA assignment where they would REALLY need docker. So last 3rd of the course just for that Linux environment.

Also note if you continue with this then I will be forced to hold a TA hostage and force them to test stuff for me and work on docker compatibility and improving the environment. See #15.

[sameer-s]

Thanks Brandon,

Sorry for the delay but I'd be down to try to go forward with cross-platform builds of everything, it seems like that's Shawn's preferred solution as well. I can do whatever's needed to help you out (that's my job now).

The main concern that came up is that if we have the MGBA emulator outside of the container, then we might have some issues with debugging/GDB if we set it up in the container. Also, for our Linux users, MGBA only provides official builds for Ubuntu. These problems should be resolvable but I just wanted to call them out here.

[TricksterGuy]

The main concern that came up is that if we have the MGBA emulator outside of the container, then we might have some issues with debugging/GDB if we set it up in the container

The GDB thing shouldn't be too much of an issue Either you can

1. Have them install arm-eabi-gdb on the host machine You can probably pull it out of a devkitpro install, or I'm sure there's binaries of it out for each OS. I had a former TA a while back tell me about how the arm compiler stuff is available on the internet for each OS.
2. Open the proper port inside the docker container and it should be able to connect with an application running in the host computer. This should work as I had a feature in complx that allowed sending a replay string to it from the host without all that clipboard mess.

Also, for our Linux users, MGBA only provides official builds for Ubuntu. These problems should be resolvable but I just wanted to call them out here.

That's also going to be an issue with complx/nin10kit since I only assume debian based system.

Going back to the history lesson, if students came in with a nonUbuntu distro, they were still completely responsible for getting the software installed on their linux system anyway.... Meaning, I made them compile the programs themselves on their computer. Otherwise they could also set up a Ubuntu VM.

I assumed those coming in with RedHat, Gentoo, and whatever it is kids are using these days already know what they were doing, and can compile stuff on their own / know how whatever package manager is on their system works.

[sameer-s]

Closing, this is no longer desired. We're working within the current setup and looking towards moving GUI apps out of Docker long-term.