Since I posted the first part in this two-part series, a friend has encouraged me to continue my experiments with WSL, even after I discovered some issues with unsupported packages when building applications from source. I must admit that after a using WSL for a while doing other things, it is growing on me!
However, I’m still curious how everything compares. I wanted to try out Linux in a virtual machine (VM). So I downloaded Vagrant to manage the virtual machines from the command line, and got Virtualbox as my VM hypervisor. I guess you could use which ever VM hypervisor you prefer.
I downloaded the latest Virtualbox release, which at time of writing was a recently released 6.1 which had an incompatability with the latest Vagrant release.
It appears that Vagrant supports Virtualbox versions specifically in it’s configuration files, and that Virtualbox’s latest release was not yet accounted for.
I came across a workaround which adds a line of code to Vagrant’s installation that allows the new Virtualbox version. Be warned though - this is a Quick and Dirty fix. I expect that in coming days or weeks that Vagrant put out an official patch.
If you also get this error then you might need to use the work around too. Otherwise you can safely skip the links below.
Windows TerminalVagrant has detected that you have a version of VirtualBox installed
that is not supported by this version of Vagrant. Please install one of
the supported versions listed below to use Vagrant:
4.0, 4.1, 4.2, 4.3, 5.0, 5.1, 5.2, 6.0
A Vagrant update may also be available that adds support for the version
you specified. Please check www.vagrantup.com/downloads.html to download
the latest version.
Workaround to allow Virtualbox 6.1 on Vagrant 2.2.6: https://github.com/oracle/vagrant-boxes/issues/178#issue-536720633
https://github.com/oracle/vagrant-boxes/issues/178
Risks
With WSL there is a risk of messing up your Linux files stored in the WSL since they are accessed in Windows. Those files can have special permissions, if altered this can corrupt them. A virtual machine uses it’s own virtual harddisk, which is seen as one big file to the host operating system (or split into multiple files if configured as such). While this could also be corrupted by the host operating system, it feels like a cleaner, more seperate approach than having files peppered all over the place in the host OS.
Using Linux in a VM on Windows
I installed Ubuntu in my VM to remain consistent and found it worked as expected.
I could download packages, install and build from source without any issues. Granted, it is a tad slower than running Linux as a native / host operating system. That is to be expected of course.
VM speed vs WSL seemed to be improved in operation. Especially the responsiveness of the terminal. This is important for me as the terminal is my main method of getting feedback from Linux-based operating systems.
DUring use of WSL I noticed a small delay in the terminal. Whenever there is a delay in getting control back in a terminal my instinct tells me that an operation I have just invoked is still running. This creates a little unease in my mind. Why is it slower than expected? What exactly is happening in the computer?
At this point I think that the WSL terminal might simply be a little laggy itself. This could be addressed by installing a mroe responsive third party terminal program, though I have not tested any alternatives as yet.
Using the VM, I did have some difficulty initially sharing files between host and guest operating systems. These difficulties can be overcome with some configuration settings and using file transfers. Check our a few online tutorials and you’re golden.
That feeling of cleaner separation between systems seems safer, however the longer boot time also seems a little more cumbersome than using WSL.
In a VM, you are simply using Linux again which is great for Linux development. Can’t complain about that! I will though.
The VM’s seperation and longer boot time doesn’t give me the same sense of closeness or readiness that I felt from booting up WSL, even though I found WSL’s terminal a little laggy. It turns out that boot time affects my perception disportortionately.
Docker and WSL
Enter my main takeaway.
Docker for Windows is fantastic and it works a charm through WSL. The Docker Daemon operates as a Windows service, and you can send it commands through the Docker CLI on WSL.
While you can easily set up Docker for your VM, the quickness of loading that WSL bash prompt has me reaching for that option each time.
Which to choose? WSL or VM approach?
I must say it’s a hard call for me, then I started using Docker. Booting up the VM takes longer than loading the WSL bash prompt. The fact that the VM uses a virtual harddisk feels better to me, but the convenience of WSL wins.
What you might choose depends on the demands of your project and personal preference. If you must do very involved development for Linux, I would say it is better to use Linux as your main OS for the proejct and forgo attempting to set up a compatible development environment on Windows altogether. I have found this a very intriguing experiment, and will likely continue with WSL for the time being, quietly hoping more linux packages become compatible as the developers work away on this incredebly powerful feature.
A thought about this series
I hope you enjoyed reading this indulgent and rambling opinion piece without the convenience of useful graphs or tables of imperical data. In the grand scheme of things it was pretty pointless endeavor for me top undertake, since there are better articles out there for you to consume than this.
I assure you it was much more cumbersome for me to write these ridiculously wordy articles and I truely hope that I learned my lesson. For your sake as well as mine. Time will tell I guess, but thanks for sticking around. If you have any suggestions let me know in the comments. Thank you!