You Can Test Windows Subsystem for Linux on Windows Server in Preview

Posted on August 9, 2017 by Paul Thurrott in Dev, Windows with 30 Comments

You Can Test Windows Subsystem for Linux on Windows Server in Preview

The Windows Subsystem for Linux is now available in Windows Insider builds of Windows Server. And as Microsoft announced earlier this year at Build, this technology will be included in the next version of the shipping product.

This is either obvious or curious, depending on your viewpoint.

That is, the Windows Subsystem for Linux (WSL) makes tons of sense on the Windows 10 client, because Microsoft is promoting this system as the only client developers will ever need, and WSL gives developers access to all of the tools they want.

But Server is, by its nature, different. And Microsoft worked, long ago—starting with Windows Server 2003 and its mantra of “it’s a server, not a surfboard”—-to remove as much of the end-user functionality in Server as possible. WSL isn’t a “Linux server,” it’s just a subsystem that enables a Linux environment with a command line shell and tools. So why would anyone want this in Windows Server?

“We want Windows, including Windows Server, to be a great place for developers,” Microsoft explains. “We know developers, system administrators, people managing services and people building services all occasionally need tools available on Linux. Many more would like to run Linux tools as part of their workflow as a matter of convenience.”

And, as Microsoft points out, those who did need Linux capabilities have had to resort to Linux virtual machines on top of Server, or third-party tools like Cygwin that are “notoriously out of date.”

So WSL is coming to Server.

To access this functionality now, you will need to download the latest Windows Server Insider build. (You must register first and join the Insider Preview.) Microsoft has also provided a handy Installation Guide for WSL on the Windows Server Insider Preview.


Tagged with , ,

Join the discussion!


Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Comments (30)

30 responses to “You Can Test Windows Subsystem for Linux on Windows Server in Preview”

  1. Waethorn

    In reply to skane2600:

    Let me help you there brother.

  2. Rob Biddle

    POSIX tools are mostly great and reliable... But, working with system configuration data structured into objects (as with PowerShell) is SOoooo much nicer than playing RegEx Roulette.

    • hrlngrv

      In reply to Rob_Biddle:

      For some things, object structures are useful. For others, say parsing long-form ls listings, plain text could be simpler, faster, and require less typing.

      In any case, preference for POSIX or Powershell is mostly subjective (there are objective pros and cons for both), but it's beginning to seem like there are more, perhaps lots more, who prefer POSIX.

      As I wrote elsewhere in these comments, MSFT erred by waiting so long to open source Powershell and let Linux, BSD and any remaining Solaris and other *nix admins learn to love it. MSFT open sourcing Powershell last year is an indication it was falling behind in admin user love. MSFT putting WSL on Windows Server is an indication it's now too late for Powershell to be much more than an admin minority alternative.

      • skane2600

        In reply to hrlngrv:

        I think you overestimate *nix folks flexibility when it comes to non-*nix tools. IMO, *nix folks would never embrace Powershell in large numbers both because it comes from MS and because it suggests text isn't the ultimate "glue" between programs.

        • hrlngrv

          In reply to skane2600:

          I may so overestimate. OTOH, you may overestimate the advantages Powershell provides. I gotta figure the reason Windows has less than 1/3 server market share isn't due to deep-seated anti-MSFT prejudice in enterprise IT shops which somehow is submerged when it comes to buying client PCs. Rather, I figure Windows servers make sense in economic terms in a minority of server scenarios.

          As for POSIX tools, if most of ones servers (Linux and other *nix flavors) can be managed with POSIX tools, wouldn't there be some economic sense to use the same tools to manage the Windows servers?

          Finally, Powershell was open sourced a year ago and made available on Linux. Prior to that do you believe MSFT had any intention of generating any love for it among Linux admins? Perhaps Powershell and MSFT are reaping what they sowed and so richly deserve? Every so often Karma can be an incredibly insufferable bitch. If there's a company more deserving of such a companion than MSFT, please name it.

          • skane2600

            In reply to hrlngrv:

            You're reading too much into what I said. I wasn't claiming that Powershell was better than posix tools or that Windows Server was more suitable than a Linux Server. I was merely claiming that most Unix/Linux folks wouldn't consider substituting their beloved UNIX tools for something made by MS no matter what the relative value.

            In recent years MS has made a lot of software open source but not any of the key bits. I think their reasons are a combination of good publicity and younger engineers at MS weaned on the open source philosophy in college (more cool kids stuff). If Powershell had been made open source earlier I doubt it would have made any difference.

  3. hrlngrv

    In reply to skane2600:

    70s tech meaning Unix?

    Consider that steering wheel and foot pedals are 1920s automobile tech. Couldn't cars be more fun to drive with joy sticks? Sometimes better loses to familar. Sometimes familiar is simply more practical, and more practical is better.

    I accept the following: . Re laziness, POSIX tools require A LOT LESS TYPING. Also, there's the inertia of collective experience. Unix had been amassing that collective experience for decades before Powershell appeared, and Powershell never became useful enough to enough admins to replace POSIX tools. Re hubris, Powershell shares something with COBOL: people who use those languages just can't generate any hubris from doing so; those languages are just too wordy, there's no mystery.

    Finally, Windows servers never surpassed anything. As for users' PCs, there have been lots of POSIX environments over the years: MKS, Hamilton C Shell, U/Win, MinGW, cygwin, now WSL. I suspect POSIX environments may have had more users (in % terms) than ModernMix did in Windows 8.x. I'd also note that FOSS uses a lot of POSIX tools, and FOSS comes #2 to Windows software development, so difficult to dismiss out of hand (which could be a legitimate reason you were down-voted).

    • skane2600

      In reply to hrlngrv:

      You could have stopped at "inertia of collective experience". IMO typing time represents about .1% of any programming activity.

      • hrlngrv

        In reply to skane2600:

        You're right. Typing time is less important than many other criteria. OTOH, terseness is likely positively correlated with quick and broad recall. Granted one could scroll down the keyword list in the Powershell ISE, but that does take time.

        The important thing is covering as much of what could be needed as possible. Unix admins have been working on that since the mid 1970s while Powershell first appeared in 2006. Let's just say that Powershell hasn't conquered the server admin market, in no small part because MSFT didn't expand it outside of Windows until last year. MSFT may have taken so long because MSFT had honestly believed it could achieve more than 50% market share in servers, and Powershell could be a marketing plus.

        Reality can be awkward.

        I don't think MSFT or Powershell have lost. Rather with Azure and online services now needing to be as inclusive as possible, numbers matter, and there really are more Linux and *nix servers in use than Windows servers, and it really may be more cost-effective to standardize on one admin toolset, and that won't be Powershell.

  4. hrlngrv

    Just possibly Powershell is too damn wordy to be useful as an administrative scripting tool.

    Not unlikely that MSFT may actually be listening to its enterprise customers, and most of them want to use the EXACT SAME command line server management tools on Windows and Linux servers. Possible corollary: MSFT should have ported Powershell to Linux earlier than a year ago in order to build up support for it rather than the POSIX tool set.

    Maybe most people who manage servers for a living prefer POSIX tools, and Powershell doesn't offer enough to overcome that preference. IOW, maybe MSFT got it wrong yet again. It happens.

    One example in closing, which would most admins prefer:

    Write-Host "Seriously?" -NoNewLine


    echo -n Seriously?

    • Rob Biddle

      In reply to hrlngrv:

      Echo is an alias for Write-Output (which you should nearly always use over Write-Host) so it's as simple as...

      echo 'Seriously?'

      • hrlngrv

        In reply to Rob_Biddle:

        Telling that echo is an alias. Also, echo is an alias for Write-Output rather than Write-Host.

        You missed the -NoNewLine bit, which is an option for Write-Host but not Write-Output. If memory serves, aliases with Value parameters which are single unquoted tokens replace that single token, but aliases which take quoted Value parameters can't handle additional parameters. Instead, what'd be needed is something like

        function yougottabekiddingme { Write-Host -NoNewLine $args }

        set-alias n yougottabekiddingme

        and then you could use the command

        n "Seriously?"

        In contrast, the *nix shell command alias n='echo -n' does nothing more than replace the token n with echo -n when the former appears as the first token in a command, allowing

        n Seriously\?

        • Rob Biddle

          In reply to hrlngrv:

          The quotes aren't actually necessary, both cmdlets expect a string as the input object.

          This works fine in PowerShell:

          echo seriously?

          You have a good point about the differing functionality of alias in bash vs PowerShell, that is an advantage when creating custom aliases. However custom aliases are only really good for individualized use, they're not overly friendly, in terms of code comprehension.

          Verbosity of cmdlets and parameter names is a very good thing when it comes to learning syntax and reading code written by others. PowerShell shines here. Once a new user understands the concepts of object structure/types and the PowerShell pipeline, then it becomes really easy to read and understand PowerShell code written by anyone, as long as the author doesn't go out of their way to obfuscate.

          • hrlngrv

            In reply to Rob_Biddle:

            My intended point was more the wordiness of Powershell vs bash.

            I understand the intended benefit of readability, which is why I drew a parallel between Powershell and COBOL. Both languages place a premium on readability over expressiveness. They're like English without contractions or idioms, arguably better for nonnative speakers, but necessarily inefficient compared to how language is used by native speakers. I gotta ask: how successful has COBOL been?

            • Rob Biddle

              In reply to hrlngrv:

              My counterpoint is that the wordiness of PowerShell in an interpreted terminal session can be reduced significantly. You can create a profile with all the aliases and custom functions a SysAdmins' heart could desire, similar to bash, so I don't see that as a reason people wouldn't want to use it. It really just comes down to familiarity with the tools.

              I think ultimately whether or not PowerShell becomes popular with Linux SysAdmins is going to depend on how much work the .NET Core & PowerShell Core dev teams put into building object definitions and output formatting templates specific to the various Linux distros and applications.

              • Rob Biddle

                Also, I would argue that PowerShell is less wordy/more terse in many cases than other languages.

                For example, Python is generally considered terse. I found a blog post espousing the terseness of Python over Java, using this bit of Python as the example:

                 print the integers from 1 to 9
                for i in range(1,10):
                    print i

                I can do this MUCH quicker in PowerShell, and output in 3 different ways at that!

                # print the integers from 1 to 9 - Output 1 digit per line


                # print the integers from 1 to 9 - Output on a single line with a space between each digit


                # print the integers from 1 to 9 - Output on a single line with spaces removed

                "$(1..9)" -replace " ",""

                • hrlngrv

                  In reply to Rob_Biddle:

                  Are we comparing Powershell to Python or bash? For bash, echo {1..10}. No, it's not as terse as 1..9, but that's a legal filename, so debatable whether it should be parsed as an expression or a filename. As for you last example, try seq -s . . .

                  I'm reasonably sure that I can come up with a shorter POSIX equivalent for any Powershell code which isn't manipulating objects or treating first tokens containing only [A-Za-z0-9_.] chars as expressions.

                • skane2600

                  In reply to hrlngrv:

                  Am I reading you right? You think POSIX is shorter than Powershell for anything except those scripting capabilities that POSIX doesn't support (e.g. manipulating objects).

                • hrlngrv

                  In reply to skane2600:

                  Terseness isn't the be-all, end-all of system admin scripting, but shorter is often easier to remember. OTOH, yes, bash and the other standard POSIX tools under /bin more often than not allow for terser commands than Powershell and whatever it may use in %windir%.

                  I'd also note that Windows servers make up less than 1/3 of all servers in use today, and the other 2/3 run Linux or another *nix variant, and all of them use POSIX tools. Weight of numbers alone make POSIX more broadly used than Powershell.

                  MSFT open sourcing Powershell last year and porting it to Linux was a sign of Powershell's strength, was it?

                • skane2600

                  In reply to hrlngrv:

                  The difficulty in remembering cryptic commands and their options is the primary weakness of all CLI's, of course.

                  Yes, Windows servers are a distinct minority and Powershell is hardly used by *nix at all. None of that means that POSIX tools are particularly useful for Windows relative to Powershell.

                  I don't thing open sourcing Powershell is a sign of anything, it's irrelevant like most of MS's open source efforts.

  5. Kirill

    "why would anyone want this in Windows Server"

    if you are using Azure for development environment i.e. VM as dev PC etc the only option you have is Windows Server. same for the jumpbox VMs which really makes it necessity to include WSL.