Linux versus Windows. It's a battle that is raged through internet forums,
spawning many a flame war. In recent years, though; Microsoft have put
down the hatchet, and started to embrace open source.
That has resulted in the birth of something that many of us never expected
to see - the Microsoft Linux kernel, and the
ability to run Linux in Windows 10. Stick around and let's
take a look.
Welcome back to The Pro Tech Show - the place for tech, tips, and advice for IT
Pros and decision-makers. Some of you are no doubt wondering "What
is he talking about? How can Windows run Linux? They're
completely different operating systems!". I hear what you're saying, but take a
look at this... This is the Windows command prompt. It's
not the shiny new Windows Terminal. It's the old boring prompt we're all used to.
Not a lot to see here. I can run DIR to see the contents of the current
directory, but i can't run LS of course because
this isn't Linux. And yes... I know PowerShell can; but that's
just because both DIR and LS in PowerShell are aliases for the
Get-ChildItem cmdlet. That doesn't work in the bog-standard Windows prompt,
as you can see; but what if i type "WSL LS" i'll explain what WSL is later.
That actually did something. Let me put a "-L" on it.
Yup. That's starting to look rather Linuxy.
Here's another staple Windows command: "CD" for the "Current Directory".
Yeah, OK, we're in "C:\Program Files\ Microsoft Office". That's definitely
Windows. The equivalent Linux command would be
"PWD" for "Print Working Directory". Obviously, that doesn't work; but what
about "WSL PWD"? Not only does that work... look at the path!
No Windows path starts with a forward- slash. That's a Linux path,
showing our Windows "C" drive mounted as "/mnt/c".
OK, sanity check. What are we running, here? That's Windows 10 Pro -
definitely not Linux. So what is this WSL thing doing?
Let's try the "WSL" command by itself. Now that...
that's Bash. That's more like a Linux terminal, and here's what happens if you
run "LS -L" now. Not only does it work... we've even got the
colours! Let's check our system info again. That
doesn't work because, that was a Windows command
and "Toto, I have a feeling we're not in Kansas anymore".
So is this Linux? If this were Linux I could find out what distribution we're
running by looking at "/etc/os-release". Now, that is not Windows.
That says Ubuntu Linux! But I've not configured the WSL command as some kind of
shortcut to SSH onto a Linux box that I just forgot
to tell you about. Let's look a little deeper and check
what kernel we're running. You are reading that correctly. That is a
Microsoft Linux kernel. Imagine trying to explain that to
someone back in the Ballmer days. It's not cancer now,
is it, Steve? So what are we looking at, here?
This is the Windows Subsystem for Linux, which i'm going to abbreviate to WSL.
There are actually two versions of this. At the time of recording, Windows will
default to using WSL1, but if you're running the 2004 version of Windows 10
or later, you might want to switch to WSL 2.
WSLs 1 and 2 work in very different ways, so it's worth explaining both of them.
WSL1 is essentially a compatibility layer. It pretends to be a Linux kernel
to the application, but it's taking Linux calls from Linux
applications then converting those in the fly to the equivalent Windows calls;
before passing them back to the standard Windows kernel. Then it converts the
response back from Windows to Linux on the return trip.
This gives you a way to run native Linux applications on Windows.
WSL2 works quite differently. Rather than pretending to be a Linux
kernel, WSL2 uses virtualisation technology
to host an actual Linux kernel, inside a virtual machine.
This means it's actual, proper Linux. This approach is a lot more efficient, because
you're not having to translate everything from Linux to Windows, and
back to Linux again. That means WSL2 has better performance
and better compatibility, compared to 1. This difference in approach is also
why the name "Windows Subsystem for Linux" feels a
little bit back to front. It almost makes more sense to think of
it as the "Linux Subsystem for Windows", but as i understand it, Microsoft weren't
allowed to start a product name with the Linux trademark
unless it used an actual Linux kernel; which WSL1 didn't.
Although WSL2 is using some of the same technology as Hyper-V; you won't see a
virtual machine in Hyper-V, and you can't log on to a
console anywhere in the usual sense. It's a highly optimised virtual machine,
with low overhead and fast startup. It's also tightly integrated with the
running Windows host. A normal virtual machine is isolated
from the host. With WSL, Linux and Windows can talk to each other and share
information with each other - blurring the lines
between the two systems. Let me show you. We're still in Linux
land here, using Bash; and i'm going to change directory to a folder on my
Windows desktop. Then i'm going to create a text file
using VIM.
OK. I know at this point somebody somewhere is furiously typing a comment
using Nano or Emacs. I... don't care. Life is too short.
Let's save that file in VIM, and here we go - straight on our Windows desktop.
I can open that in Notepad, save it, open it in VIM again; and you can see the
changes. Seamless file access between Windows and
Linux. You can also do this in reverse by
typing "\\WSL$" in Windows to get to the Linux filesystem.
Let's do something a little more visual.
If this is Ubuntu, I can install Webmin, right?
Let's get that running. Now, how do i access it?
If I was running Linux, I could open a browser and go to localhost;
but because i'm running Windows, localhost refers to my Windows computer...
or does it? WSL is clever enough to know that port 10000
has just been grabbed by Webmin in Linux, and it automatically redirects
that through from Windows. So i can just browse to localhost on
Windows, and reach Webmin as if it was running natively on Windows.
Now we've got something visual, I'll just click through the filesystem to show
you can indeed access Windows files from Linux;
including the live "System32" directory, if you really wanted to.
That's pretty cool. Could we push it a little further and deploy something like
Nextcloud? Yes; and i did. "http://localhost/nexcloud" and there we go.
That's Nextcloud, running on Apache, on Ubuntu, on the Microsoft Linux kernel,
on Windows. The ability to run Linux natively in Windows is
really interesting... but what exactly is the point of this?
Am I suggesting that Windows admins who find themselves needing to deploy Linux
services should deploy those in Windows using
WSL? No. Just build yourself a Linux server.
There's no sense in over-complicating it, or limiting yourself like that. If you
need Linux in production, deploy Linux; not Linux on Windows.
So what is this for? Well you could use it for a few things, really, and I've got
an interesting one to show you later in the video;
but the explicit reason Microsoft created WSL was for developers.
A lot of developers use Windows; but just because the developer works in Windows,
and develops in Windows, doesn't mean the application they're writing is going to run
on Windows. Let's say you're developing an app for
Nextcloud. You might want to develop it in Visual Studio on Windows,
but you're going to deploy it to run on Linux.
In that case, the ability to run Linux locally on Windows for testing and
debugging would be a great time-saver. The same argument goes for cloud
development. The fact is that most developers are
running Windows, and most cloud services are not. You can make arguments all day
long about which operating system is better,
but if you're deploying to the cloud and you've outsourced all of the operating
system management to the vendor then most of these arguments are
irrelevant. What it really comes down to is this:
do you need a specific runtime or integration that only works on a
specific platform? If not, and someone else is managing it
for you... well what you're left with is Linux is usually the cheaper
subscription option. So that's the reason the Windows subsystem for Linux exists;
but it's not the only reason to use it. It might be an easy way to start dipping
your toe in if you want to give Linux a try;
although, honestly, I'd recommend installing it as a full virtual machine.
You'll learn a lot more if you start from the beginning, and
there are weird little gotchas with WSL if you try to treat it like a standalone
server. Like rebooting. I've not really found any
way to reboot the underlying virtual machine, other than shutting down WSL.
An interesting use case I've stumbled across, though, could be for penetration
testing. You've seen me running Ubuntu; but that's
just one example. WSL uses the Microsoft Linux kernel, but
you can install different distributions on top of that.
Funny enough, you install your Linux distributions from the Microsoft store.
Who'd have thought that was coming? We've got a few options there,
including SUSE and Debian, but this isn't the full list, either.
Watch this. That's fedora. Fedora that you pay for, mind. My brain isn't quite sure
how to process that yet. In fairness, that Fedora distribution is
not endorsed by the Fedora Project or Red Hat.
It's a third-party remix. The third party has put in a lot of effort to pack up
the Fedora derivative and make sure it plays nicely with
Windows, so it's fair that they could expect to be compensated for it.
It's just that paying for Fedora feels almost as weird as running Linux in
Windows. But anyway. That Fedora remix isn't what
i wanted to show you. What i wanted to talk to you about was
Kali. If you're not familiar with Kali; it's a Linux distribution filled with
all manner of security tools. The kind that can be really useful to
a security researcher; or can land you in prison, depending on
what you do with them. The really interesting thing about Kali
and WSL, is that they've come up with a way to give you
access to the desktop experience. The reason you've only seen me use the
command line or a web interface so far, is that WSL does not support a
traditional graphical interface. There's no actual console you can log on
to. That's not as much of a limitation as it
might seem, because most Linux systems are configured to only provide a command
interface anyway. Running a desktop on a server is often
considered to be bad practice. But watch this as a load up Kali... Just to
show you again, this is Kali Linux with the Microsoft Linux kernel.
Look at what happens if i run "KEX". I'm now in the full Kali desktop ,in
Windows. There is a bit of cheating going on here.
This isn't running natively. If I hit F8 you can see what's really
happening. This actually loaded a TigerVNC
client in Windows, and used it to remote onto the desktop of the WSL machine
running Kali. But I have to say, it seems to work quite
well. Now, full disclosure - I've not done much with
this other than load it up, go "ooh", and open a few apps; and i don't know if
there's any gotchas to be aware of; but i do know a lot of pentesters use
Kali to run their tests, and then go back to Windows to write up
their reports. Being able to run both from within Windows, and have easy access
to any testing exports from Linux in Windows seems like it could be a handy
time-saver. What about you? Have you found any
interesting uses for the Windows Subsystem for Linux?
Comment below, and upvote your favorites. I'm really interested to see what you
guys come up with. That's about all for me today, though. I'm
going to go engage the Coffee Subsystem for Andrew, and in the meantime I'll leave
you with a couple of other videos to watch
over here. If you found this one interesting, then give it like before you
go; and don't forget to subscribe for future
videos. Thanks for watching, guys. See you next time!