Here we are, part 5 of the “Make Windows green again” blog series hot off the press and maybe things so aren’t as shiny anymore as initially thought? In part 1 we discussed how to inject openSUSE Leap into WSL, we then discussed in part 2 how to get the user setup right again. Part 3 was (maybe) the pinnacle with getting graphics to run – and first obstacles were hit. An rather easy one to fix was discussed in part 4, but there are certainly more of those ahead of us. So looking at the curve of excitement, is the vale of tears ahead of us?
Not at all. While it’s absolutely great to always have high hopes and demand for the best, a quick reality check is something in need right now. First of all (and that one goes on me, I forgot to do this much earlier in this blog series), let’s give kudos to the Microsoft WSL team for making this technology initially available. There is an excellent blog series on WSL and I strongly recommend everyone to read it in its entirely. Casual Linux users will certainly learn something as well, because it’s not just Microsoft technology discussed there. The blog series is available via https://blogs.msdn.microsoft.com/wsl/ and you’d need to start reading the bottom blog first – or you just follow this list from top to bottom:
- Windows Subsystem for Linux Overview
- Pico Process Overview
- WSL System Calls
- WSL File System Support
- Bash on Windows 10 Anniversary Update
- Windows and Linux Interoperability
- WSL Antivirus and Firewall Compatibility
- WSL Networking
Admittedly, a lot of material – but certainly a must for everyone in need for a deeper understanding of the mechanics. If you feel that this is too much to read (or you are not in need of a deeper understanding – which is absolutely fine too), here’s the executive summary for you:
A huge amount of work has been conducted by Microsoft to create WSL (like mapping Linux syscalls to Windows syscalls, etc). However, currently WSL is still missing some key capabilities to make Linux run as if it would natively. All of that is however in the works and might be added to future versions of WSL. Now, allow me to add the following sentence as well, as this is a very important topic for some Linux user as well. “Some features of Linux, like the built-in Security and Open Source principles, might never be fulfilled by WSL, as there will always be a native Windows OS in play.” Replacing Windows 10 with Linux would be the only way to satisfy such a demand. But that’s not what this blog series is about.
Some fixes to graphics
While “plain” xserver applications like xeyes, xclock, gkrellm, xterm are working quite fine when using openSUSE on WSL, others like gnome-terminal or similar simply quit out with an error message like:
libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Exhausted all available authentication mechanisms (tried: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS) (available: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS)
Is there anything we can do about it right now?
WSL already implemented crucial syscalls and maps those to their Windows counter parts. But, a few important ones are still not there. Some of those are providing UNIX socket functionality, a key requirement for most of the Gnome and KDE applications using dbus. For some applications it might be enough to change the dbus session.conf file under /etc/dbus-1 and replace
… and if we are lucky, some applications are now going to work – while others still don’t. There is a public github project called WSL-Programs where you will find a quite comprehensive list of how well (or not) Linux binaries run on WSL. I encourage you to perform your own tests with openSUSE Leap binaries (not just the graphical ones, but also regular ones running in the terminal). When posting test results, please ensure to add a remark about openSUSE Leap in the comment field.
The next blog will discuss the possibility to get access to a more recent version of WSL using Windows Insider builds.
Until then, happy Linux’ing 🙂