WSL2: goodbye VIM, hello VS Code

Summary

This post will go through using Visual Studio Code (VS Code) as the “native” file editor for Linux by leveraging the Windows Subsystem for Linux 2 (WSL2). Cross-platform development between Windows and Linux has been made simpler over the years since the introduction of Windows Subsystem for Linux. Gone are the days of dual boots, hypervisor VMs, or multiple machines to get started in developing between Windows and Linux. However, until WSL2 I continued to use both Windows and Linux native editors for each environment. In Windows it is Visual Studio or VS Code and in Linux it is VIM or nano.

With WSL2 it is now possible to edit the direct Linux filesystem files from within VS Code in Windows which reduces the need for VIM/nano and provides IntelliSense for known file types. A very transparent editing experience with high productivity.

Prerequisites

Description

The intent of this post is not to compare VIM to VS Code or claim one is better than the other. Code/text editors strike passion in anyone who does any type of substantial editing, particularly if attempting to convince them there is a better one than what they are using. This passion is fully justified and what is the right editor for one may not be right for someone else. Regardless of editor; Notepad, Notepad++, Word, VS Code, Visual Studio, Eclipse, VI, VIM, nano, etc. if the one you are using makes you productive, then that is the right editor for you. After all, computing was intended to make our lives more productive, not less (a tidbit I sometimes find overlooked in the spirit of innovation).

The problem WSL2 and VS Code has solved, is if we are productive using VS Code based on its capabilities and extensions, such as IntelliSense, Source Code Management, etc., we want that productivity to carry across Windows and Linux filesystems.

WSL2 is a feature of Windows 10 that allows running a full Linux Kernel instance on the same machine utilizing its hypervisor technology, Hyper-V, effectively running a lightweight Linux VM on Windows. Yes, the summary is less than truthful by stating hypervisor VMs are gone. It is still there and the enabling technology for WSL2, however, we do not need to manage it ourselves, thus making us more productive. This virtualization technology enables us to view and edit the Linux filesystems from Windows using VS Code.

Next we will go through the steps of getting WSL2 installed and configured with VS Code integration to see this editing in practice. However, VS Code will not replace VIM, only make its use a little less (for my editing), and if we so choose we can even run VIM within VS Code as will be highlighted in the steps.

Steps

1. Install the Windows Subsystem for Linux 2 (WSL2) utilizing the Microsoft Installation Guide

2. Install the ‘Remote-WSL’ extension for VS Code

Install of Remote - WSL extension in VS Code

3. Open a Command Prompt and list installed WSL subsystems and their versions by typing:

C:\Users\Torben\wsl --list --verbose
Windows Subsystem for Linux 2 instances and versions

4. Optional, I had WSL (v1) instances installed prior to running WSL2. One of these, Ubuntu, was configured for WSL2 by running the following command:

C:\Users\Torben\wsl --set-version Ubuntu 2

5. Using the WSL2 shell, in this case for Ubuntu, log in to the terminal.

6. Enter the following command to install the VS Code Server on Linux and launch VS Code in Windows from the current directory:

$code .
Install VS Code from Linux terminal

7. VS Code should launch into a WSL session showing the instance, Ubuntu, with a directory and file listing for the current directory.

VS Code connected to Ubuntu WSL showing the Linux directories and files

8. Using VS Code, we can now open and edit the files directly, including a terminal window inside the editor for executing bash commands within Linux.

Host editor with terminal running Ansible

9. The Ubuntu WSL terminal can now be closed and all file editing and terminal commands can be executed directly within VS Code.

Goodbye VIM? Well, not really. I will continue to use VIM (and nano), particularly when working on systems with no WSL support or Windows. However, getting VS Code extensions and IntelliSense support for known file types while editing them directly on the Linux filesystem is a nice productivity boost.

Should the urge/need be there to continue editing with VIM, we can also perform that action while staying within VS Code using the terminal window. This gives us an editor-in-an-editor experience where changes in VIM shows up in VS Code (and vice versa). (Haven’t found a huge need for it, but pretty neat capability none the less :-))

10. Using the example from step 8, we keep the ‘hosts’ file open in the VS Code editor window and use the bash terminal to edit the same hosts file in VIM

Edit hosts file in VIM

11. Enter a new host entry, ‘piorange’ in VIM

Added piorange to hosts file in VIM

12. Save the change and close VIM

Save change in VIM

13. Notice the VS Code editor version of the hosts file updates automatically to show the new change ‘piorange’

Enjoy!

Next Steps

  • Will this work if Windows and Linux are on separate machines and not using WSL2?
    I don’t know but suspect the answer is no as of this writing, but perhaps someone can confirm. I could see it is a nice-to-have feature, but seems to stretch the intent behind WSL2 of being productive in a closed system loop between Windows and Linux.

The Future of Bookqueue

A new chapter is about to start for Bookqueue!  As highlighted in a previous post – “Bookqueue, we have a problem”, new challenges presents new opportunities. How the journey will end is unknown as of this writing, but at this time Bookqueue is continuing on.

Bookqueue was originally created to serve my family since its inception in 2012. The family and community has been great supporters of the application over the years and finding this new challenge has not made anyone particularly happy.  Especially my spouse and you probably know what they say “When Mommy isn’t happy…”. So, we are going to work on getting Bookqueue back to making everyone happy!

Short-term

There are short-term bug fixes and updates that will come to Bookqueue to remove crashes and provide better error information. This will include removal of localized Amazon countries where Bookqueue usage was low and subsequently blocked. The outcome of these changes should bring some stability to the application although its capabilities will be limited in nature under current constraints.

Mid/Long-term

Ideas are starting as to how we can bring Bookqueue capabilities back to full throttle. These include ways for how our family and community members can help drive advertising revenue activity within a continuous 30-day timespan to satisfy the Amazon Efficiency Guidelines and not be throttled. We are still seeking to limit the ‘book sell’ feature of Bookqueue but may have to move from a passive to a semi-active process to meet Amazon guidelines.   Alternatives to utilizing the Amazon advertising system as the content provider are being considered but at a low priority as Bookqueue’s value has been directly attributed to Amazon’s backend systems.

I plan to provide periodic updates when available, but welcome community feedback if you have suggestions as to how Bookqueue can thrive in the new norm. Happy reading!

Bookqueue, we have a problem

Bookqueue, we have a problem. I have recently observed and been notified by Bookqueue users of crashes and error messages stating that it is submitting requests too quickly. Initial symptoms indicated a bug in the application but once I started to debug I discovered that (beyond bugs) the issue runs much deeper.

The main problem that has come up is that Amazon has changed its request throttling logic as of January 23rd, 2019 based on new Efficiency Guidelines. Though the change in Amazon’s guidelines has directly impacted the usability of Bookqueue, I want to stress this is NOT Amazon’s fault.  Instead, the impact is caused by opposing design intents between Bookqueue and Amazon.

To give some history, Bookqueue, came about in 2012 based on a family need to help better find and manage books. We were/are avid eBook readers (particularly my spouse) using Amazon Kindles and found ourselves buying books on a continuous basis. The continuous basis ended up creating a pre-purchased queue of books for future reading. This ‘pre-purchased queue’ created an opportunity to not only help our bank account but also our mental buyers remorse of not reading a previously purchased book when coming across a new book of greater interest. Many applications were available at the time to solve this, such as goodreads, but we were interested in something more targeted to our needs. Hence the first release of Bookqueue for Windows Phone 7 in 2012.

Bookqueue v1

First Bookqueue release on Windows Phone 7

Bookqueue Information Architecture

Original Information Architecture design for Bookqueue

As we were targeting Amazon’s Kindle book catalog, Bookqueue takes advantage of a public application programming interface that Amazon utilizes for its affiliate partners to advertise its full product catalog, not just books. It is this interface that is impacted by the new Efficiency Guidelines. Back in 2012 and up until January 23, 2019, there has always been an effective throttle limit adhered to by Bookqueue as to how frequently it could call the interface for book searches, descriptions, author searches, similar book searches, etc.

Until now, frequency, has been the only factor applied to the throttle limit for using the advertising interface. The new guidelines adds a second factor in the form of – generated advertising revenue. This advertising revenue is generated by Bookqueue if a user chooses to go through Bookqueue’s link to view the book on Amazon and subsequently purchases the book on the Amazon website.

Some Bookqueue users have utilized this feature to purchase books in the past which provided small advertising revenue to buy a book every now and then and has been greatly appreciated. However, direct advertising revenue was not a driver for Bookqueue because its primary design function was to create value for the book reader, not selling books. Selling for revenue was the lowest priority of Bookqueue, hence the reason it started out and remains free of in-app ads.

This brings us back to the beginning of how Bookqueue is impacted by the new Amazon efficiency guidelines. As the new guidelines are in effect, Bookqueue has not generated advertising revenue in 30-days which has triggered the multi-factor throttle limit on requests. Additionally, inactivity (no usage) in countries with localized Amazon regions has caused the advertising interface to be closed completely.

Now what?

Without doubt, Bookqueue’s value for the past many years has been completely attributed to Amazon’s incredible product advertising system. It is also understandable that Amazon has to manage their operational efficiencies and balance the cost of supporting an advertising system against its generated revenue. This balance places Bookqueue in a challenging position to its future as to whether it can be successful under these constraints.

I don’t have an answer yet – but will offer the following suggestions to existing Bookqueue users:

  1. The Future of Bookqueue – outlines current thinking to what changes Bookqueue will see should you choose to follow us further in the reader journey
  2. Export your Bookqueue books – provides a step-by-step guide as to how you can retrieve all your books from the app in case your Bookqueue journey ends now

Regardless of your decision to continue or leave Bookqueue, I would like to thank the community for the incredible feedback and support you have provided through the years. Our family’s reader experience has benefited from your many feature suggestions and input. As always, your comments/feedback to this post and the future of Bookqueue is much appreciated.

Thank you!

Note: this article also applies to Bookqueue’s sister application, Moviequeue.