I have had a dream of running Linux on the desktop in a business environment for a long time.   

Linux and the Free Open Source Software (FOSS) tool chains that it supports  are a staple for many IT professionals.  They are widely used for IT heavy lifting tasks such as Web development, data science, system administration and penetration testing.  

A number of Linux based operating systems such as Google’s Android and Chrome OS, or Valve’s Linux / SteamOS have been highly successful in specific markets.  Linux is the dominant operating system for high performance computing, and a major player in cloud and corporate datacentres.

And yet, The Year of Linux on the Desktop is more of a running gag at this point.

The key challenge with Linux on a business desktop is that most business environments run on a Windows ecosystem that is not friendly to Linux.  There are gaps in support for many enterprise grade products that make it difficult to integrate Linux workstations.

This is largely an issue of scale.  Why would organisations invest in support for Linux when it has so little a share of the desktop?

One common way for IT professionals to solve this problem is to use virtualisation or containerisation tools to run Linux under Windows.  Where frequent access is required, Apple Macs are often used as a development workstation as they provide access to both a UNIX based environment and the Microsoft tools and drivers required for integration with enterprise Windows ecosystems.  

With the introduction of the Windows Subsystem for Linux, an alternative is available.  

“Hell has frozen over and you can run Linux on Windows” 

A Native Linux IT workbench for Windows

The Windows Subsystem for Linux (WSL) is a Windows 10 feature that allows you run Linux programs directly on the Windows Kernel.  Native Linux applications run alongside Windows applications. The two operating systems share resources and can communicate with each other. 

The ability to both integrate with the Windows ecosystem and access to tools from native Linux distributions allows you to create a Linux IT workbench within a Windows environment. 

WSL provides a lightweight alternative to Linux virtual machines or containerisation.  It can replace a collection of Windows add-ons such as PuTTY and MinGW, and can avoid compatibility issues with Linux tools that have been ported to Windows.   

This is primarily a tool for developers, especially web developers and those who work on or with open source projects. This allows those who want/need to use Bash, common Linux tools and many Linux-first tools (Ruby, Python, etc.), to use their tool chain on Windows.

Most likely this will require changes to workplace IT network and security solutions to support WSL integration into existing firewall and AV configuration, and to provide secure access to Linux distributions.

Rampant speculation

There is plenty of speculation about this product.  

Clearly Microsoft are encouraging the migration of applications and development from Linux to Windows.  This is similar to the approach they used to enable application migration from OS2 to Windows.  

This feels a little like the famed Embrace, Extend, Exterminate strategy.  The ability to mix and match Linux and Windows commands in the one command line, or to combine Microsoft tools such as Visual Studio with Linux utilities, will create blended tool chains that only work on Windows desktops.

There are several Linux features that Microsoft does not plan to implement under WSL.  For example Microsoft do not plan to support Linux GUI desktops or applications, and they provide alternative solutions for containerisation and virtualisation of Linux workloads.  Applications that provide their own Linux kernel extensions, or require direct access to the hardware will not run natively under WSL (for example Docker).

Will this create a market for “helper” applications that bridge the gaps, or encourage migration of these tools from Linux to a Windows based development?

The future Windows direction of FOSS products are less clear.  Will there still be a need for Windows ports such as MinGW or tools like PuTTY when you can run the native Linux equivalents inside of WSL?  Alternately, which FOSS products will still require Windows ports to overcome gaps in WSL capabilities?

Does this undermine the need for Apple Macs as a developer workstation?

Who knows?  Perhaps this will be the Year of Linux on the (Windows) desktop!

Further reading and things to try.

Microsoft resources

• Where to start learning about the Windows Subsystem for Linux: https://docs.microsoft.com/en-us/windows/wsl/about.  Contains the WSL installation guide, FAQ, troubleshooting and release notes.
• Windows Subsystem for Linux Overview: https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/.   For people who are interested in the history of the Windows subsystem feature, and the architecture of the WSL. 

• More detail on Pico processes, the sandbox that hosts Linux processes in WSL:  https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/

• Extensions to provide AV and Firewall integration with WSL.  https://blogs.msdn.microsoft.com/wsl/2016/11/01/wsl-antivirus-and-firewall-compatibility/

Other resources

• The most “Awesome list dedicated to the Windows Subsystem for Linux” can be found at https://github.com/sirredbeard/Awesome-WSL.  This includes information on how to setup WSL; a list of official and unofficial (eg Fedora) distributions; How to integrate with Ansible, Azure, Docker, etc; Running X servers and Linux desktops (Gnome, Xfce, Kde).
• How to install a LAMP stack on WSL: https://medium.com/@ssharizal/how-to-install-lamp-stack-server-on-windows-subsystem-linux-wsl-windows-10-133419c22473
• How to run xfce4 on Kali Linux over WSL using the remote desktop protocol: https://youtu.be/wIH-bwdWRGM
• Adding rules to Windows Defender to allow Kali Linux to install penetration testing tools: https://www.simontaplin.net/configuring-windows-defender-e/.

… or how to get unsupported stuff to work on Linux.

Every now and then, you are likely to find yourself with an unsupported gadget or two.

In my case I needed a wifi adapter for my new Raspberry Pi 2. Rather than consult the lists and order one online (the right thing to do) I let my impatience get the better of me and grabbed a Netgear A6100 while passing through local electronics store.

Netgear is a well known brand, should be supported, Raspberry Pi’s support all manner of devices out of the box, dont they?

Unfortunately the Netgear A6100 did not work, and a little research showed this particular device was not on the supported WiFi gadgets list.  Hmm…

Rather than dropping it in the unused bits box and waiting for a supported device to arrive, this seems like the perfect opportunity to get another strange and perverse contraption to work.

The need – a Raspbian Linux device driver for the Netgear A6100 WiFi USB adapter

After a little googling, I found that a Netgear A6100 needs the Realtek rtl8812au driver.  There are copies of the source available on github.  In order to build a device driver you first need to have the source code for your running kernel.  This is where the fun starts :).

Before we start, a few useful resources

• Linux Kernel in a Nutshell contains a great introduction to building the Linux kernel and device drivers from source and explains many of the concepts you will need to get started.  The book was written by Greg Kroah-Hartman one half of the Linux stable release team. This can save you a lot of time.
• The Raspberry Pi Foundation Kernel Building and Configuring the Kernel pages give you the specifics you will need to build a Raspberry Pi kernel and device drivers.
• There is a concise description of how to compile the Raspberry Pi kernel at elinux.org.
• It is useful to grab the example Hello World loadable kernel module.  If you can get this to work then you are more than half way there.

Building and installing the kernel

Before you can build a device driver a copy of the kernel source is needed.  This needs to be the same version as the operating system you are running or the driver will not load.  You can either search for the source to your current kernel, or build and install a new kernel.

The Raspberry Pi is underpowered compared to a typical Intel based workstation.  If you plan to rebuild the kernel frequently then cross compiling on a more powerful system may be a better choice.

The instructions here are for rebuilding a new kernel directly on the Raspberry Pi.

It is a good idea to build your Linux kernel from a user account, and not the root account.  The additional permissions of the root account are not needed until you are ready to install the kernel.

The Raspberry Pi comes with two different chipsets, one for the earlier models A, B and B+, and one for the newer Raspberry Pi 2.  Some of the steps are slightly different depending on which model you are building for.

Login under your pi account, download the latest linux kernel source from the GitHub and install any required additional software:

$ git clone --depth=1 https://github.com/raspberrypi/linux
$ cd linux
$ sudo apt-get install bc ncurses-dev

Configure the kernel.  It is best to start with the default configuration and modify it if needed.

To load the default configuration for Raspberry Pi models A, B, B+
$ make bcmrpi_defconfig

To load the default configuration for the Raspberry Pi 2
$ make bcm2709_defconfig

Alternately you could copy the current running kernels configuration if it is available.
$ gunzip -d -c /proc/config.gz >.config

You may need to modify the configuration to remove an unneeded module.  In my case one of the ADSL drivers did not build correctly so I removed it.  Another reason to do this is to trim down the running kernel to just the components you need.

$ make menuconfig
Search for and disable any modules you don't want.

The make -j n switch can be used to build the kernel in parallel, saving time.  Usually you would set n to two times the number of processors.  For example on a Raspberry Pi 2 you could use -j 8.

Time to build the kernel

$ make -j 8
$ make -j 8 modules

And finally to install the kernel you will need access to the root account

$ sudo make modules_install
$ sudo make install

For Raspberry Pi models A, B, B+
$ sudo cp arch/arm/boot/Image /boot/kernel.img     
For the Raspberry Pi 2
$ sudo cp arch/arm/boot/Image /boot/kernel7.img

Reboot your Raspberry Pi and check with uname -r that you are running the version you expect.

Building and loading the Hello World example module is a great way to test that everything is in order before moving on to build the driver.

Building the Netgear A6100 device driver

A quick search on GitHub should bring up a couple of rtl8812au drivers.  One example: https://github.com/gnab/rtl8812au.

Copy the driver
$ git clone https://github.com/gnab/rtl8812au

You will need to make sure that the version you downloaded supports the A6100 device.

Insert the A6100 dongle 
$ dmesg     
...
[ 3.607714] usb 1-1.4: Product: 802.11ac WLAN Adapter 
[ 3.615123] usb 1-1.4: Manufacturer: Realtek 

This shows that the device is recognised by the hardware.

$ lsusb
...
Bus 001 Device 004: ID 0846:9052 NetGear, Inc.

The ID numbers are used by the operating system to locate the required device driver.  By searching the driver source code for this ID you can confirm that it supports your device.

$ grep -i -R USB_DEVICE rtl8812au | grep 0846 
...
rtl8812au/os_dep/linux/usb_intf.c: {USB_DEVICE(0x0846, 0x9052),.driver_info = RTL8821}, /* Netgear - A6100 */

Now that we know we have the right driver source, it is time to build and test the driver.

$ make
$ sudo insmod 8812au.ko

If this is successful your new wireless interface will be visible to ifconfig or wpa_gui, the WiFi config application.

Install the module by copying it to its new home and updating the kernel dependencies.  Sometimes the make file can do this for you, however you can do this by hand with:

$ sudo cp 8812au.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless
$ sudo depmod

You should now be able to configure your new Netgear A6100 WiFi adapter.  The instructions can be found here.

One happily working gadget

Fool me once, shame on you, fool me twice, …

A few days after purchasing the Netgear A6100 I was shopping in a different store and noticed the Edimax USB adapters.

Hmm… Edimax was on the supported list …

I will post an update when I find a way to get the Edimax AC450 to work.