In the Talentoday tech team we have regular discussions about the best Operating System (OS) workstation configuration for the team. While experienced engineers are free to choose what they prefer, it is reasonable to recommend and maintain a kind of preferred configuration for interns and juniors to facilitate the setup and onboarding. Talentoday tech stack being *Nix based, for long most of the developers were using MacOS with MacBooks. This is definitely an acceptable solution but we confronted that, and some of us (me included), started to use Linux distributions. However, I did not find yet an ideal setup. I will share here some criticisms about various OS configurations and discuss the new Microsoft WSL2 and see how this could be the best of both all worlds, yet to be confirmed.
Usual OS configurations, main flaws
First I am presenting here my main criticisms, as you will notice most are not on the technologies themselves but more on their daily usage within a team and a potential large fleet of devices.
Windows OS. Unless you develop solely .NET applications (the regular .NET FX not the new .NET Core) that can only run on Windows OS then, Windows is probably not the ideal dev OS. While Python interpreters work well on Windows some other technologies, like Ruby for instance, are really a pain on Windows. It is a fact that most of developer tools and technologies are not thought for Windows (or at least not as a first class citizens). On the positive side, administrating the team machines would be easier compared to others. Indeed, Windows is really adapted for maintaining a large fleet of machines and most everyday applications run perfectly on Windows. Unfortunately, this latter argument does not counterbalance the poor dev experience on many technologies.
Linux standalone OS setup. In this case, you have a real Linux OS that will probably be the closest thing that hosts and runs your applications in production. Using Linux, you can use a great package manager such as apt. Good code editors like VSCode or Sublime work perfectly. Yet… in the real world other problems arise. First, the ones that are due to Linux desktops and window manager themselves. For example, having different resolutions and scaling for your screens is not well supported unless you go with Weyland. Well with Weyland you will stumble on troubles for sharing your screens. In our team, we do remote work, we need to share things when huddling. We have to present to clients and teammates around the world everyday. You need a comfortable setup with multiple monitor and the ability to jump on in case clients invite you on a GoToMeeting, Zoom.us or whatever videoconf system and this needs to work. Similarly, it happens frequently that we receive *.xlsx, *.docx files with macros that only Office desktop can process. Therefore, even if you manage to have everything working on your Linux desktop workstation there are things, independent of your will, that can sometimes be problematic.
Dual boots. Honestly, I never was really convinced by dual boots. It is quite cumbersome. In addition, most of the time you need to disable secure boot, which is, for a company setup, probably not a good recommendation.
Leveraging virtualized OS. That’s an option and here are two possibilities. First, host OS is Windows/MacOS and you develop in a guest Linux. Well if you are a developer your primary work will probably be development, then, even though you can make your VM as seamless as possible, it is always preferable to do your everyday work in the host OS. The other way is setting a guest Windows OS (you cannot guest MacOS) on Linux host. Again, some problems like sharing your Linux screen for showing your local devwork will not go away. Let me also point out that you depend a lot on the hypervisor and its ability to handle well displays. My experience proved me that this is often bugged. Fixing this kind of bugs does not seem to be the top priority of hypervisors. Take for example Oracle and VirtualBox that keeps ignoring for years this bug on HighDPI screen.
Mac OS. It seems that this has become a very popular solution for developers in the past decade. This is the configuration that I have now for almost two years and it works! Nevertheless, there are some criticisms that cannot be ignored. Even if MacOS is Unix based and POSIX compliant this is no Linux. This makes a bit of difference: you cannot use apt-get but you have to rely on Homebrew instead. Small stuff that make your local config different from the prod systems. One can not ignore that Docker For Mac also has some serious flaws. In addition, it is clear that maintaining a fleet of Macbook Pros is quite a pain: no native group policies . For device maintenance, you have to go with Apple support etc. Finally, the cost associated with purchasing Macbook Pro compared to its equivalent at Dell is higher (even that is not so much as it is often mentioned in discussions).
The best of all worlds? Windows 10 with WSL2?
WSL stands for Windows Subsystem for Linux. At the time of writing its first version WSL1 is shipped on all up-to-date Windows 10 builds, to get access to WSL2 you need to register to Windows Insider Program and retrieve a preview build.
With WSL, Microsoft brought a Linux Kernel inside Windows 10. It can be used directly from within Windows host using a bash shell. In its first version, it was really useful for many small tasks, such as sshing easily from Windows (and not relying on PuTTy). Yet, some limitations on networking and filesystem did not make it a viable solution for an everyday developer workstation setup. WSL2 is now a much more complete solution that makes usable for development (involving a full VM on top of Hyper-V that some may even see as a regression).
In addition, some really important news came along. First, the popular code editor VSCode fully supports WSL2 and brings extensions. Second, and probably more important, Docker in the latest tech preview edition of Docker Desktop let you use WSL2 to run the containers.
If you are working on existing projects, there is a strong possibility that some (if not all) of your services leverage Docker. Therefore, you must have a way to run and access Docker containers from your new WSL2 environment. This was our situation at Talentoday where we rely a lot on Docker.
I tried to install our *Nix based Talentoday stack on Windows 10 with WSL2 and it worked like a charm.
As a big overview, at Talentoday, the applicative server services are built on top of Ruby on Rails (with jobs and queues etc.) accessing SolR indexers. We also have a cache mechanism on top of Redis, a PostgreSQL database and a Flask based Python WebAPI. For the developer experience, we rely a lot on Docker containers (including the database) for this various components. With the Docker Tech Preview, I had no problem building and starting my images and contacting them within WSL2 and accessing them from both WSL2 code and/or host Windows.
We will need some step back and see if WSL2 is the right way to go in the long run. We will have to pursue our investigation and see if there are no other problems (performance, networks etc.) that I could not spot during this one day trial. In all cases, this early attempt sounds extremely promising and could be a good solution for developers in teams who want to keep the benefit of a commonly distributed OS and a real developer experience leveraging *Nix based technologies.
