Installation of WSL
While professing a Network Operating Systems course, I had the opportunity to introduce the students to the new Windows Linux Subsystem (WSL). Above is a nice little video tutorial I did on how to get it up and running with little to no effort. I would like to expand on it and give a little history as to why this feature is so cool.
Ecosystems
My home is a diverse ecosystems of technologies, a plethora of wireless protocols, and infinitely diverse. As each component in the network differs in purpose, trying to take a one operating system to rule them all approach seemed senseless.
To maintain sanity, I needed some sort of structure, albeit loose.
- Desktops and Laptops that are workstations will run Windows 10
- Desktops and Laptops that are servers will be assumed headless and run the latest Ubuntu Server
- If a Desktop or Laptop needs to function in both a server/workstation role, it will run the latest version of Ubuntu Desktop
- Raspberry Pis will run whatever the most recent version of Raspbian they can support
- ESP8266/ESP32s will run ESPHome unless they absolutely focus around a component that is not yet supported
Why Windows?
Hardware support mostly, Program support sure, GUI and feature set, 100%. Without getting into the Linux vs Windows debate, I treat my operating systems like they are tools to a job, and if the tool does not fit, I do not spend 90% of my time modifying it, I just grab another. I will concede that this is all personal opinion, but speaking for myself, Windows on the Desktop, Linux on the Server. I will also conceded to special use cases. One such use case is Kimmy, our Karaoke box. Kimmy needs to be able to take in, filter, and spit out audio from multiple USB microphones with unnoticeable latency, something I found impossible in anything above Windows 7.
A Stranger in a Strange land
Now I know I just said I do not spend a lot of time modifying a tool before reaching for the shelf, but hear me out. It takes an incredible amount of work to make Linux reach desktop parity with Windows. Some things I have done are.
- Wine
- KVM
- KVM with virt-d pass-through
Some of these things worked fine. I still have a KVM pass-through box accessible via voice control should the better half want to play computer games in the same room. But they all ended up being overly complex solutions to a straightforward question.
What I am trying to say is, it is a lot easier to modify Windows to fit your need for Linux as a daily driver, then it is to do the inverse.
In the past there was the Putty SSH client, my expensive graphics card would sit there and power three or four screens of terminals, as if it was a glorified dumb terminal. Putty was fine, you could do up some samba and edit your files from windows, running commands through putty.
Then came along Cygwin, (Babun Shell being the last iteration I used), giving you a basic POSIX system inside of Windows, sure for more complex stuff I would still terminal in, but for simple things, Cygwin sufficed.
Life was good, no longer was I using Putty, my terminal emulator supported XTerm256, and PowerLine icons, I could use an ssh-keygen agent without running a dedicated application in the task tray and converting to a Putty key format. It was almost like I was in Linux, but in Windows.
Aside: Yes, there was always VNC, but I generally do not want to stand up a X stack with all the things that come with it for a server that is operating headless. That being said, the folks behind flatpak, snaps, and appimages have done wonders in making Linux more accessible for the average user. My recommendation as far has a VNC solution will always be tigerVNC, with its up to date XRandr support and built in encryption.
Then it happened
Something inside the head of some senior engineer over at Microsoft eventually clicked, and the convergence of two worlds were set in an inevitable collide. No longer would the skills you invested in Windows be useless in Linux, no longer would the power of the Linux CLI remain removed from Windows. Engineers around the globe stood united in their confusion, some peeking out the window for signs of brimstone and snow.
It seemed like just yesterday I had to run a special utility to delete a NodeJS project because Microsoft had a weird max file path limit hard coded into their file system, and now I can Bash with the best of them.
Jokes aside, that is not really the reasoning behind this. They more likely realized they were not as competitive in the Architecture as a Service market since people would lean toward their competitors who offered Linux powered instances, avoiding a large seat price for Microsoft Server. Looking to not lose relevance, and missing yet another paradigm changing technology (they were kind of late to the whole Internet fad), rather then double down, Microsoft finally formed a plan.
Introduce the Windows Linux Subsystem:
Not a VM, not a container, not a Kubernetes, or whatever buzz word we make in 2019, a Subsystem! What this means is there is no virtualization involved, WSL sits on a layer of direct mapping to the Windows Kernel system calls. This allows Linux binaries to run inside of Windows unmodified. It is actually very sweet. Microsoft originally partnered with Canonical (Owners of Ubuntu) to work on this feature, with the initial release providing Ubuntu in the Windows store. Has time as passed even more distributions have been added, giving you not only Linux in Windows, but even a choice of flavor. Fun fact, it is sometimes quicker to just rm -rf inside a WSL terminal then it is to delete the same files through explorer, even when avoiding the Recycle Bin.
Introduce Typescript:
Object Oriented Languages were losing hype to Functional Languages. JavaScript was popping up all over the place, the client, the server, under the stairs, if it could run Node, there be JavaScript. If you had just picked up JavaScript today, you might be asking, what is wrong with it? Why did Microsoft feel the need to write an entirely separate language that just transpiles down to it? This is mostly because hopefully you started with learning the current ECMA standard. You luckily avoided things like Callback hell, the scope of this, and a list of other nightmares. Even today though, one thing JavaScript is not is type safe, and as a NodeJS developer, I have seen what happens when there are too many cooks in the kitchen on a loosely typed project. Typescript aimed to solve a lot of these problems by providing the rigid structure the already established Microsoft stack developers were used to, magically turning into the language those same Microsoft stack developers have been bashing ;)
Release Visual Studio Code:
Microsoft was losing relevance in Editors to things like Atom, Brackets, Sublime. I will admit, Visual Studio is a wonder to work with, and has some excellent features. But for people working on a more Web oriented stack, many of those features were not really needed nor justified the purchase price. If one was going to put down money, they would more likely fall on a JetBrains product, offering all the goodies at a fraction of the price with none of the bloat. Before Visual Studio 2017, the editor was a notorious CPU/Ram hog and could exhaust lower end workstations sitting idle. They solved this problem by introducing Visual Studio Code, a editor reminiscent to Atom/Brackets, running inside an Electron shell. Visual Studio code gave them a install base, exposed them to the novices just picking out their first glorified text editor, and gave them a release channel for things like first party .Net support, and first party Typescript support.
Contributing to Angular:
Microsoft had no idea what the hell they were doing on the front end of the web. Do not believe me? Go google ASPX. Sure that is an example of Web 1.0 but sometimes that rigid structure I mentioned above does not work, and one of those places is inside the browser. The only thing that kept them going was their dominance in the Web Browser market, and their complete control of the proprietary ActiveX. Thankfully, rather then try their hand at yet another Front End Framework, they collaborated with the likes of Google to commit to Angular 2, a complete rewrite of the already Popular Angular JS, and as a plus, they decided to release it in TypeScript, upping the bar of entry, but greatly increasing the maintainability in a large dev team.
Finish .NET Core:
Microsoft was losing relevance in the Programming Languages sector to things like JavaScript / Python / Go / Kotlin / Rust /Ruby / etc.. To combat this they began their VNext project that was eventually renamed to .NET Core, starting with C# they rewrote the language to be cross platform (and interestingly compiled using a compiler written in the language it is compiling). This gave them ASP MVC Next, providing a MVC solution that can operate on both a Linux and Windows stack, written in C#. The other big hurdle was first and third party module support, for example, Entity Framework was written from scratch and crawled to parity.
Finish MsSql Port:
Well this one is obvious, MariaDB, Mysql, MongoDB, CouchDb, anywordDB... are biting in to that sweet sweet MsSql money, and making people who have put 20 years into learning MsSql a little dated. If Microsoft was going to provide a cloud service that supported Linux, a Web framework that supported Linux, they were going to need a Database server that ran on, you guessed it, Linux! I won't touch on the details of this, rather I will defer to a great article on TechCrunch.
Provide Sysinternals Port:
Sysinterals is a suite of utilities to monitor and control processes and other resources. It was kind of like the Microsoft version of a POSIX set of tools. Spend most of your life in Sysinternals and do not want to worry about porting your skills over to the other side? You are in luck, they are slowly porting the suite over to the land of GNU, starting with ProcDump.
Release PowerShell port and unify it with Windows:
PowerShell is to Windows as Bash is to Linux. Replace the default black background white text with a blue background with white text and you have the best thing to happen in Microsoft CLI since DOS. It comes complete with its own module system, and is highly expandable. It has a very weird syntax in my opinion, borrowing some code quality standards from .Net, ByUsingTitleCaseFor-Everything.
There is no denying it is powerful, but even so it was often overlooked in alternative to learning Bash . It also makes it difficult for a Powershell guru to transfer their skills over. Not a problem, Introducing Powershell for Linux (there is even a first party snap)! Phase one was releasing PowerShell for Linux written around .Net Core, with some disparity between the Windows version, still based on the .Net CLR . Phase two was announced recently, with a new release for Windows coming out shortly, targeting .Net Core.
It is now worth my time to 'Get Good' at Powershell.
Add NFS Support (Win 10 Pro / Enterprise, Win Server):
This one is little known. We are just very used to sharing hard drives between platforms using CIFS/Samba. It is almost a second nature to begin the config process every time I provision a new box. Before I list the advantages of NFS over Samba, let me first mention the main disadvantage. Samba 3.0 released a new feature called Multichannel, allowing you to utilize multiple network cards to increase overall speed of a transfer. What this means is, if you had two network interfaces on both the client and the server, all connected to the same network, you could essentially double your data transfer. This does not require bonding or any advanced network configuration, it just works out of the box on the Windows side, on the Linux side it is a config line and making sure you force the newest Samba version.
Now the advantages, UIDs/GUIDs! Finally, I can mount a drive in Windows from a Linux NFS server and it respects the GUID/UID I tell it to, rather than the weird permission system in Samba. I do not know if it is just me, but this was a very exciting feature.
You can find a quick explanation here.
Joining the Open Source Initiative:
Microsoft decided to support Linux in a large way, with its wallet. You can read more information here.
Acquiring GitHub:
This one is kind of a mixed bag, causing the most die hard of open source contributors to exit the platform and hop on a competitor, but like it or not, Microsoft does own GitHub. There really is nothing closer to the open source community then the platform that hosts the majority of its content. Entire ecosystems are build around the services that GitHub provides, without it many of the package managers we hold dear would cease to function. Your builds that are dynamically pulling, those updates you needed to do for security, when GitHub goes offline, those often become real pain points. A few years ago GitHub went offline for longer than 15 mins, we called it a Developer Snow day...
Conclusion
Maybe Microsoft suddenly fell head over heels for Linux, more likely they feared becoming irrelevant to the likes of Amazon, but despite the catalyst, the results are commendable. I am all for the seamless unification of Linux in Windows, I get to take full advantage of my shiny hardware, while not having to jump through hoops to remain productive. A part of me fears this is all a very long con to destroy open source by consuming it, something Microsoft was very good at in their youth, but the majority of me remains optimistic.
Maybe my next personal project will be written in .Net Core, pulling data from a dockerized Linux MsSql server, deployed through Powershell, who knows. It is at least a actual consideration when weighing my options now, and I am sure it was not lost on them that I would not mind my day job language translating into my hobby language.
Maybe I am just rambling on about the things Microsoft has done to make me take them more seriously moving forward. Thanks for taking the time to read :D I hope you enjoyed.