Dual Boot is Dead: The Post Mortem



Original Source Here

Dual Boot is Dead: The Post Mortem

Turn any machine into a developer workstation with one command.

Image by Gergely from Pixabay

Two years ago, I had one issue: On one hand, the company I was working for was a heavy Microsoft product user. Microsoft Office was essential for my work. At the same time, I prefer to do my programming work on a Linux machine. A Windows VM inside my Linux environment was running too slow.

So, the solution I came up with was a simple one; I decided to dual boot Ubuntu and Windows 10. Dual boot was the answer for a long time. However, one million context switches later, Windows Subsystem for Linux, or WSL for short, was released. I decided to give it a try and started moving a portion of my workflow to Windows and WSL.

Still, many things were missing. But WSL 2 came, and it seemed to be a game-changer. One year later and WSL 2 still has not fulfilled its promise or potential. Maybe it will, someday, but I need something now. Moreover, since I am working remotely, I need something portable, a development environment that I can take with me and set it up in under 10 minutes.

This story presents two solutions to address this problem and how to combine them to get the best results! This combined solution has been working for me great so far, but I am keen to hear your counsel in the comment section below!

Learning Rate is a newsletter for those who are curious about the world of AI and MLOps. You’ll hear from me every Friday with updates and thoughts on the latest AI news and articles. Subscribe here!

A Portable Base Station

First things first: when I sit down to get some work done, I need three things:

  1. My favorite code editor
  2. The project I am working on
  3. The project’s dependencies

I am a Machine Learning Engineer, so I am fiddling with Python scripts most of the time. My favorite code editor is Visual Studio Code. So, this is an algorithm I could follow when I sit in front of a brand new workstation:

  1. Clone the project from GitHub
  2. Create a python virtual environment (python -m venv venv)
  3. Activate the environment (source venv/bin/activate)
  4. Install the dependencies (pip install -r requirements.txt)

Seems pretty straightforward, right? Not at all! First, do I have Git installed? If not, I have to install and configure it. Do I have the correct version of Python installed? If not, I have to install pyenv, install the version of Python I need, and start over. Do I even have venv installed? This is a nightmare.

So, let’s use Docker. Let’s package the project and its dependencies inside a docker image, ready to become a dev container in no time. But do I have Docker installed and configured to talk to a registry? This begins to get on my nerves.

I need a portable base. Something that I can setup up quickly. Something that has all the core elements already there: Git, Docker, Python even a single-node Kubernetes cluster for testing my deployments.

Enter Vagrant. To get my portable base workstation, I have to execute the steps of the following algorithm once:

  1. Start from a basic Ubuntu Vagrant box
  2. Install and configure everything I need: Git, Docker, K3s, other Debian packages I need, etc.
  3. Package my environment in a new Vagrant box (vagrant package --output workstation.box)
  4. Upload the box to Vagrant Cloud

Now, when I sit in front of a brand new workstation, all I have to do is install Vagrant and VirtualBox and pull my Vagrant box from Vagrant Cloud. This takes under 10 minutes, and it is available forever after.

The Code Editor

The next step is to tackle the code editor issue. I prefer to use Ubuntu without a GUI when I’m running it inside VirtualBox. It just makes things a lot faster and easier. The terminal environment is more than enought.

However, I said before that my favorite code editor is VS Code. So, how can I use it inside the VM now? Should I just use ViM?

While ViM is really great, and I use it every day, especially if I’m working inside Jupyter, I still prefer to work in VS Code.

Visual Studio Code is a free, lightweight, and cross-platform code editor. It may not be a full-fledged IDE like IntelliJ Idea or PyCharm, but it is a powerful, distraction-free tool with a dedicated fanbase and a thriving ecosystem.

What is more, VS Code has one extension that will keep your environment clean and your projects isolated and maintainable. One that will allow you to work from anywhere on any project. One that will permit you to collaborate with anyone in your team without any hassle. Welcome to the beautiful world of remote development.

The Remote Development extension for Visual Studio Code is the only extension you will ever need to install on your local VS Code setup. Using it, you will be able to work inside the development environment that you want; do you need more resources? A specific Linux distro? Specialized hardware? Not a problem.

Thus, you can use its Remote SSH variant to connect to your VM. Moreover, any extension you install inside the VM is installed there, so it does not pollute the core VS Code installation. To read more about how to set it up and use it, head to the story below:

Summary

Two years ago, I had one issue: On one hand, the company I was working for was a heavy Microsoft product user. At the same time, I prefer to do my programming work on a Linux machine.

Dual boot was not working for me in the long run, so I turned to WSL 2. One year later and WSL 2 still has not fulfilled its promise or potential. I needed something portable, a development environment that I can take with me and set it up in under 10 minutes.

My solution is summarized in the following five steps approach:

  1. Install VirtualBox
  2. Install Vagrant
  3. Install VS Code and the Remote extension
  4. Pull my “workstation” box from Vagrant Cloud
  5. SSH into the VM and start working

This solution is portable, you set it up once, and it is there forever. Moreover, its setup takes under 10 minutes, it is easily maintainable and extensible. Feel free to adopt it, but most of all, feel free to suggest anything I can do to improve this. As an ML engineer, I always search for opportunities to improve the algorithm.

About the Author

My name is Dimitris Poulopoulos, and I’m a machine learning engineer working for Arrikto. I have designed and implemented AI and software solutions for major clients such as the European Commission, Eurostat, IMF, the European Central Bank, OECD, and IKEA.

If you are interested in reading more posts about Machine Learning, Deep Learning, Data Science, and DataOps, follow me on Medium, LinkedIn, or @james2pl on Twitter.

Opinions expressed are solely my own and do not express the views or opinions of my employer.

AI/ML

Trending AI/ML Article Identified & Digested via Granola by Ramsey Elbasheer; a Machine-Driven RSS Bot

%d bloggers like this: