x11docker: docker-for-win: --vcxsrv: X cookie authentication fails

Thank you for your thoughts. You have said some important points to consider.

As a start, I have published runx v0.1. It allows to provide VcXsrv in WSL. It can be sourced in ~/.bashrc or directly run e.g. runx xterm. I might extend it for MSYS2 and Cygwin, too.

It can also be used for x11docker in future. This will allow me to drop some Windows code from x11docker.

I want to support x11docker in at least WSL. runx might make it easier to keep support for Cygwin and MSYS2, too.

These thoughts are not technical at all, though. I would like to hear your thoughts about this.

I must agree with you on almost everything. They also did bad lobbywork around here for several years, and they are still doing it, specially targeting education. I am aware about the case of Munich too. It was such a sad new.

Supporting x11docker on good old Cygwin, but not supporting the hype WSL to not support Windows development.

I think that this might be incoherent. Although I would prefer having Cygwin support rather than not having support at all, I think that it is not consistent to support Cygwin and not WSL. Both are solutions to use GNU/Linux tools on Microsoft’s Windows. Both of them rely on some free, other open, and other closed source pieces of software. The difference between them is mostly technological. I.e., if someone was to write a HyperV-based Cygwin today, the architecture would probably look quite similar to WSL.

Moreover, both installing and using Cygwin is harder than either WSL or GNU/Linux. A common GUI user which needs to start using terminal apps might be confused about WSL being much easier, and it might lead to thinking that Microsoft’s Linux is easier than a regular GNU/Linux. I think that, from a strategic point of view, it is better to let new users mix windows and linux binaries almost seamlessly. Hopefully, at one point they will be using all linux binaries without even realizing about it.

Supporting X on WSL (with and without docker) to make Linux GUIs on Windows available, thus making Linux famous. (However, a much shorter but well done script could suit this better.)

I think that x11docker can signifficantly help in this sense. According to the demos, it will be possible to launch a windows GUI app from WSL. So, users might feel that Linux is not for regular apps, because GUIs only work on windows. A simple script (which calls x11docker, or an independent one) sourced in .bashrc can solve this, as you say. A very interesting user group that might benefit from this are developers of apps with GUIs (including videogames) which use frameworks with multi-platform support.

---

I also think that the Windows part of the codebase is getting too complex, so I agree with you when you point out that in a few months a single and straighforward solution should be kept.

At the same time, the main reason for me to switch from my own script to x11docker was Windows support. On GNU/Linux, it is straighforward to share the X server on the host with any docker container. Hence, it is easy to set up, even by hand. However, on Windows it is not so easy. Therefore, if Windows support was dropped, I would probably need to stick with the current version. For me, it is prioritary to have a common syntax on both platforms, because it allows me to write all the scripts and development assets once. I could wrap x11docker with my own ‘entrypoint’, which I did in the past; but this would imply that I would not use any x11docker feature which I am not able to replicate on Windows on my own.

In the end, it is going to be mostly your time and effort, so I completely understand if you do not want to support Microsoft at all, be it because you are angry or because of any other reason.

This sounds slightly contradictory to me. You have stated before that you’d rather drop VcXsrv support instead of providing an unsecure default. However, you are suggesting to use VcXsrv here. Does this mean that xauth works in WSL without requiring Cygwin/X?

Yes. Tools like xauth or xwininfo can be installed in WSL with e.g. apt-get install xauth. x11docker could declare this as a dependency like on a regular Linux system and can use them directly without cmd.exe workarounds or path conversions and carriage return issues. It also provides a better mkfifo support than Cygwin and MSYS, an issue we had in the early x11docker-on-Windows days and is currently fixed with an ugly and time+CPU consuming workaround.

Things would also become easier if x11docker supports Cygwin/X only, but I assume WSL(2) will supersede it in future.

I don’t know for sure whether it’ll be possible to run the daemon on the underlying VM (the one running the linux kernel, where all the containers are executed). If this later approach is possible, docker-for-win itself might not make much sense.

AFAIK docker will run directly on the WSL2-Linux-Kernel. It is not possible in WSL1 due to missing kernel features (cgroups). There will be no need for the current Docker-VM setup. That might also fix odd bugs like #104.

I believe that, at some point, Microsoft will provide a built-in X server, just as they are providing a VM with a Linux kernel and rewriting part of MSYS. At that point, neither VcXsrv nor Cygwin/X will be required. However, I found no reference about this yet.

There has been some requests in the WSL Github tracker, e.g. https://github.com/microsoft/WSL/issues/2356. It seems to be out of scope currently, but who knows. Either way, if with VcXsrv or a built-in X, x11docker will be able to provide it to container applications.