Anything that you can script out in Windows 10 has likely already been done and is in a PowerShell script somewhere on the internet. Meaning, if people need a script, they can google their use-case scenario, such as "transfer all images in one folder to another" and then add "powershell" to that search term in Google. You'll find a fair amount of results and other users that might be able to help you.
Anything that you can script out using Bash has likely already been done on a variety of Linux, Unix, BSD systems. Same thing here as before, quite a few users familiar with Bash and these open-source operating systems.
There's a lot less support for Bash (which could only be done through some kind of terminal emulator before) on Windows 10.
So why would you bother? The people who'll need BASH support on Windows 10 (which this is the only place this is getting official support for, not Windows 7/8, etc.) won't find it easily, so they'll go for the lower-hanging fruit with PowerShell.
If someone REALLY wanted an open-source terminal and support for open-source Bash scripts, they'd already be an open-source operating system to start with.
I think it's not about being open source, it's more about using what you're familiar with. Many developers aren't familiar with powershell and would prefer using bash when they're using windows. Many companies have both Linux and windows servers (for example where I work we used to have storage and web servers running Linux, and Database servers running Windows with SQL Server), in which case I think it would be useful to be able to use the same scripts on all your infrastructure.
I'm not saying it's a killer feature, but it could be a nice addition in some situations.
Let's face it, this is surprising coming from Microsoft. Nadella is definitely a different leader than Ballmer and Gates. But some things, like implementing BASH, I find conflicting because Microsoft already has an alternative, superior scripting language. I mean features don't hurt, I'm not complaining, I just find it curious to devote resources to adding a feature like this.
It's to get developers to move to Windows. And a company wants to make $$$ and not waste their expensive developer time in rewriting CL-Scripts from bash to powershell. Yes you might find it on the internet, still the guys doing will need to learn PowerShell, adjust all the scripts, test them and document them. Depending on the process that can be a lot of tedious and useless work which hinder develeopers from switching to Windows.
Keep in mind this is ultimately about mobile. More Windows Store devs = more windows mobile Apps.
It's not uncommon for a FOSS tool to either only have a bash script for setup/config or to have a .bat file that's significantly out of date or less capable than the .sh that the tool developers primarily use. Reducing cross platform friction here is a good thing.
It also looks good from the other direction, eg an ASP.net developer with a Redis layer in the tech stack. On the dev machine you can run the Linux version of Redis directly instead of needing to use a VM.
What you are missing here is that some people just want to get work done, and some people don't have a choice of their operating system kernel.
So, to get work done, they found someone who already scripted a simple solution in bash. They install a few supporting packages with apt-get, maybe download a source tarball, and make it, and then they get to work.
They won't use powershell because their starting point isn't a cmd window, its a scripted workflow that someone else already created on linux, or OSX.
Yeah, I definitely can think of no situations where it'd be massively advantageous to be able to target win and nix in one shot with bash. I most certainly didn't spend over half my time writing an automated testing script porting it over to windows.
I mean really you're asking why would you want to target a prevalent OS with a good tool? Why indeed.
> feedback was that a lot of the development tools they use require Bash scripting making it difficult to do the development on Windows
Outside of .NET dvelopment, lots of existing projects are easier to compile and get it running on Mac OS X and Linux. Windows feel like a sub-par development environment, and Microsoft notices that they will get left behind if they don't fix that.
SSH and Bash shell are must-have tools to make Windows not longer a red-headed step-child. I am very glad Microsoft is making this happen. It shows they are opening their eyes and ears.
It's still something you need to download (and get approval to use in an enterprise environment) as opposed to having a native way to SSH into a remote computer.
People use open-source packages to develop Web sites (and do plenty of other stuff) under OS X. I also use an Ubuntu chroot (crouton) on a Chromebook in dev mode, which this sounds weirdly similar to. Also using regular old Ubuntu on this desktop.
I think users will just go to whatever setup gets them what they want--the tools they want for server-side development, the familiarity or hardware support or whatever they get from their client OS.
To go one step further, one of the neat things about open source is that if someone is willing to do the work and comply with licenses, it can be ported to most any environment, no "strategy tax" or IP/contractual issues in the way (at least from the OSS side). That seems to have played a part in OSS reaching the position it has now. So I wouldn't dismiss unexpected uses of OSS like this, I'd say they're an example of what's neat about open source in the first place.
This is more than bash scripting, and the article is really incorrect to present it as such. This is a much bigger deal.
Microsoft has implemented the whole Linux kernel API in the NT kernel. This allows the ability to run Linux binaries unmodified on Windows. Yes, binaries, unmodified, without the need to port or even to recompile.
This is a colossal improvement over Cygwin and everything else that's been available for Windows. It's even an improvement over OS X, I don't have to do gymnastics to replace all the ancient BSD utilities that Apple ships with OS X with their GNU counterparts.
And those of us who teach/train people in Python/Ruby/Go don't have to fret anymore when someone shows up with a Windows laptop.
For me, the interesting question is how devices will be treated. Can I do dd if=/dev/zero of=/mnt/d for example?
You had me until you said Go (Golang for the sake of simplicity); Go didn't have much problems with Windows being one of its selling points compared to the truly *abysmal* experience it is to try and use Ruby on Windows or pain to have many Python packages installed (let alone the Python 2 vs Python 3 split Python infamously has)
Go's os package of course had specific public functions that weren't applicable or problematic to use until this news about Windows 10 upcoming update (or the one immediately after the BUILD conference to finally enable most developers to be productive with a WIndow's cmd.exe)
Yes Go definitely has had much better Windows support than Ruby or Python, but it is just one of the many tools that has not been well suited to Windows. There are a lot of these technologies around, from Ruby and Python, to Git and many more.
When I was starting in this industry, the environments that most people learned in were Visual Basic and Delphi, and their home was Windows. Now when I look at what kids are starting with, it's mostly web technologies, JavaScript, Ruby/Python/Go (and Java and Objective-C/Swift if they care about mobile) and their dev environments of choice are Linux or (mostly) OS X.
Somewhere along the way, Microsoft lost the interest of a whole generation of developers.
Now I can see that Microsoft is trying to win these people back, and frankly this is the best way they could have done it. Providing Linux ABI compatibility as a NT subsystem is way beyond anything I expected from Microsoft. It will instantly make Windows a proper tool worthy of consideration for developers like myself.
And might I add, with proper package management available in the form of apt-get, Windows now offers a much better environment than even OS X, with its clunky and half-baked Homebrew and MacPorts.
That's good news, even it it isn't a true "revolution".
What would be more exciting would be more native interoperability with Linux system. Like, does this come with native support for EXTx file systems on Windows?
As for the differences: cygwin has been around for ages and works pretty well despite feeling like an alien, however many of the differences you just mentioned also apply to OS X and yet it feels pretty Linuxish under the bonnet nowadays but obviously Apple wouldn't partner with Microsoft to give them the same edge...
As for drawing more developers to Windows: good luck with that, enabling Linux/OS X/BSD/<you name it> "workflows" (basically only those relying on bash, which is a clear pointer to autoconf/automake) on Windows is only the smallest step of many. As long as the rest of the tools continue to suck this won't fly anywhere... And why use Windows natively if it is much simpler to crosscompile e.g. with MXE.
Cygwin uses the ancient POSIX compatibility layer that's been around in Windows since NT 4.0, and presents all its own weird problems. Everything has to be ported to Cygwin, which is no easy task. Also, Cygwin is dog slow. Writing to a modern SSD at 10 MB/s is not particularly novel in 2016.
This is a very big deal, it allows running Linux binaries unmodified on Windows. No need to recompile anything, no need to port anything to another weird POSIX. All the Linux binaries that people know and use and are maintained well, on Windows.
This is an impressive bit of engineering. Sure NT has always had the ability to run different userspaces, and it did have a POSIX environment and and OS/2 environment for a while, but those provided source compatibility. Translating every Linux API syscall to NT? And doing so at native speeds? This is hugely impressive.
For the first time in a LONG time, I'm really excited about something in Windows. Heck for the first time in a long time, I might actually think about buying a Windows laptop next.
Yes indeed, it is very similar to the Linux compat layer that the BSDs have long provided.
From a computer science perspective, this is nothing new. Back in the late 90s and early 2000s, there was a product called Win4Lin from NeTraverse which did the opposite of this, it translated Win 95 syscalls to the Linux kernel and allowed Windows binaries to be run "natively" on Linux. Problem was it only supported the Win 9X branch, and once the Windows userland moved to NT, it became obsolete.
It takes a fair amount of engineering to pull something like this off, but it is not novel from a programming point of view. It does mean that Microsoft now has to track the Linux kernel API to maintain compatibility, but that's fairly stable so it's a low-risk strategy. Still, in this age of virtualization and containerization, I did not expect to see something like this from Microsoft. Kudos to them.
POSIX subsystem only provided source compatibility with Unix (and like all other versions of Unix, had its own peculiarities which meade porting software very difficult to it).
This is binary compatibility, translating Linux kernel syscalls to to the NT kernel. Very different kettle of fish.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
41 Comments
Back to Article
Pinn - Wednesday, March 30, 2016 - link
Powershell is probably better, but you have enough people with Linux/mac backgrounds to need this kind of thing.JoeyJoJo123 - Wednesday, March 30, 2016 - link
Yo dawg, I heard you like open-source terminal APIs, so we hooked you up with Bash so you can open-source inside your closed-source...Oh wait... Why would you bother with Bash if you can just use it in a truly open-source operating system?
lmcd - Wednesday, March 30, 2016 - link
You want some 2% reality with that idealism?JoeyJoJo123 - Wednesday, March 30, 2016 - link
Would you like 2 cents of reality?Anything that you can script out in Windows 10 has likely already been done and is in a PowerShell script somewhere on the internet. Meaning, if people need a script, they can google their use-case scenario, such as "transfer all images in one folder to another" and then add "powershell" to that search term in Google. You'll find a fair amount of results and other users that might be able to help you.
Anything that you can script out using Bash has likely already been done on a variety of Linux, Unix, BSD systems. Same thing here as before, quite a few users familiar with Bash and these open-source operating systems.
There's a lot less support for Bash (which could only be done through some kind of terminal emulator before) on Windows 10.
So why would you bother? The people who'll need BASH support on Windows 10 (which this is the only place this is getting official support for, not Windows 7/8, etc.) won't find it easily, so they'll go for the lower-hanging fruit with PowerShell.
If someone REALLY wanted an open-source terminal and support for open-source Bash scripts, they'd already be an open-source operating system to start with.
BlueScreenJunky - Wednesday, March 30, 2016 - link
I think it's not about being open source, it's more about using what you're familiar with. Many developers aren't familiar with powershell and would prefer using bash when they're using windows. Many companies have both Linux and windows servers (for example where I work we used to have storage and web servers running Linux, and Database servers running Windows with SQL Server), in which case I think it would be useful to be able to use the same scripts on all your infrastructure.I'm not saying it's a killer feature, but it could be a nice addition in some situations.
Samus - Thursday, March 31, 2016 - link
Let's face it, this is surprising coming from Microsoft. Nadella is definitely a different leader than Ballmer and Gates. But some things, like implementing BASH, I find conflicting because Microsoft already has an alternative, superior scripting language. I mean features don't hurt, I'm not complaining, I just find it curious to devote resources to adding a feature like this.beginner99 - Thursday, March 31, 2016 - link
It's to get developers to move to Windows. And a company wants to make $$$ and not waste their expensive developer time in rewriting CL-Scripts from bash to powershell. Yes you might find it on the internet, still the guys doing will need to learn PowerShell, adjust all the scripts, test them and document them. Depending on the process that can be a lot of tedious and useless work which hinder develeopers from switching to Windows.Keep in mind this is ultimately about mobile. More Windows Store devs = more windows mobile Apps.
DanNeely - Thursday, March 31, 2016 - link
It's not uncommon for a FOSS tool to either only have a bash script for setup/config or to have a .bat file that's significantly out of date or less capable than the .sh that the tool developers primarily use. Reducing cross platform friction here is a good thing.DanNeely - Thursday, March 31, 2016 - link
It also looks good from the other direction, eg an ASP.net developer with a Redis layer in the tech stack. On the dev machine you can run the Linux version of Redis directly instead of needing to use a VM.http://www.hanselman.com/blog/DevelopersCanRunBash...
I think Scott got a little confused about the difference between Emacs and Vi in his editor snark midway down the article though.
easp - Monday, April 4, 2016 - link
What you are missing here is that some people just want to get work done, and some people don't have a choice of their operating system kernel.So, to get work done, they found someone who already scripted a simple solution in bash. They install a few supporting packages with apt-get, maybe download a source tarball, and make it, and then they get to work.
They won't use powershell because their starting point isn't a cmd window, its a scripted workflow that someone else already created on linux, or OSX.
xthetenth - Wednesday, March 30, 2016 - link
Yeah, I definitely can think of no situations where it'd be massively advantageous to be able to target win and nix in one shot with bash. I most certainly didn't spend over half my time writing an automated testing script porting it over to windows.I mean really you're asking why would you want to target a prevalent OS with a good tool? Why indeed.
stun - Wednesday, March 30, 2016 - link
> feedback was that a lot of the development tools they use require Bash scripting making it difficult to do the development on WindowsOutside of .NET dvelopment, lots of existing projects are easier to compile and get it running on Mac OS X and Linux.
Windows feel like a sub-par development environment, and Microsoft notices that they will get left behind if they don't fix that.
SSH and Bash shell are must-have tools to make Windows not longer a red-headed step-child.
I am very glad Microsoft is making this happen. It shows they are opening their eyes and ears.
JoeyJoJo123 - Wednesday, March 30, 2016 - link
Ever heard of PuTTY?Duraz0rz - Wednesday, March 30, 2016 - link
It's still something you need to download (and get approval to use in an enterprise environment) as opposed to having a native way to SSH into a remote computer.bernstein - Wednesday, March 30, 2016 - link
sure but i'll gladly replace that with bash+opensshGigaplex - Thursday, March 31, 2016 - link
You can use PuTTY as an SSH client, but not as an SSH server. Microsoft is bringing a native SSH server to Windows.twotwotwo - Wednesday, March 30, 2016 - link
People use open-source packages to develop Web sites (and do plenty of other stuff) under OS X. I also use an Ubuntu chroot (crouton) on a Chromebook in dev mode, which this sounds weirdly similar to. Also using regular old Ubuntu on this desktop.I think users will just go to whatever setup gets them what they want--the tools they want for server-side development, the familiarity or hardware support or whatever they get from their client OS.
To go one step further, one of the neat things about open source is that if someone is willing to do the work and comply with licenses, it can be ported to most any environment, no "strategy tax" or IP/contractual issues in the way (at least from the OSS side). That seems to have played a part in OSS reaching the position it has now. So I wouldn't dismiss unexpected uses of OSS like this, I'd say they're an example of what's neat about open source in the first place.
aryonoco - Wednesday, March 30, 2016 - link
This is more than bash scripting, and the article is really incorrect to present it as such. This is a much bigger deal.Microsoft has implemented the whole Linux kernel API in the NT kernel. This allows the ability to run Linux binaries unmodified on Windows. Yes, binaries, unmodified, without the need to port or even to recompile.
http://blog.dustinkirkland.com/2016/03/ubuntu-on-w...
This is a colossal improvement over Cygwin and everything else that's been available for Windows. It's even an improvement over OS X, I don't have to do gymnastics to replace all the ancient BSD utilities that Apple ships with OS X with their GNU counterparts.
And those of us who teach/train people in Python/Ruby/Go don't have to fret anymore when someone shows up with a Windows laptop.
For me, the interesting question is how devices will be treated. Can I do dd if=/dev/zero of=/mnt/d for example?
lilkwarrior - Thursday, March 31, 2016 - link
You had me until you said Go (Golang for the sake of simplicity); Go didn't have much problems with Windows being one of its selling points compared to the truly *abysmal* experience it is to try and use Ruby on Windows or pain to have many Python packages installed (let alone the Python 2 vs Python 3 split Python infamously has)Go's os package of course had specific public functions that weren't applicable or problematic to use until this news about Windows 10 upcoming update (or the one immediately after the BUILD conference to finally enable most developers to be productive with a WIndow's cmd.exe)
aryonoco - Thursday, March 31, 2016 - link
Yes Go definitely has had much better Windows support than Ruby or Python, but it is just one of the many tools that has not been well suited to Windows. There are a lot of these technologies around, from Ruby and Python, to Git and many more.When I was starting in this industry, the environments that most people learned in were Visual Basic and Delphi, and their home was Windows. Now when I look at what kids are starting with, it's mostly web technologies, JavaScript, Ruby/Python/Go (and Java and Objective-C/Swift if they care about mobile) and their dev environments of choice are Linux or (mostly) OS X.
Somewhere along the way, Microsoft lost the interest of a whole generation of developers.
Now I can see that Microsoft is trying to win these people back, and frankly this is the best way they could have done it. Providing Linux ABI compatibility as a NT subsystem is way beyond anything I expected from Microsoft. It will instantly make Windows a proper tool worthy of consideration for developers like myself.
And might I add, with proper package management available in the form of apt-get, Windows now offers a much better environment than even OS X, with its clunky and half-baked Homebrew and MacPorts.
lilkwarrior - Thursday, March 31, 2016 - link
You're absolutely right about apt-get vs Homebrew & MacportsKlimax - Thursday, March 31, 2016 - link
Reminder: POSIX Subsystem. Aka longest survivor of all alternative subsystems in Windows NT branch.Daniel Egger - Wednesday, March 30, 2016 - link
"sudo-native"? Sounds more like pseudo-native is the more appropriate term here.Cygni - Wednesday, March 30, 2016 - link
#damn #dang #burnedJoeyJoJo123 - Wednesday, March 30, 2016 - link
#TyrannosaurusREKTBrett Howse - Wednesday, March 30, 2016 - link
I was in my Linux world when I wrote that :)nightbringer57 - Wednesday, March 30, 2016 - link
That's good news, even it it isn't a true "revolution".What would be more exciting would be more native interoperability with Linux system. Like, does this come with native support for EXTx file systems on Windows?
MrSpadge - Wednesday, March 30, 2016 - link
Considering how hard native interoperability of Linux with Linux can be I'd be surprised if they went very far.hechacker1 - Wednesday, March 30, 2016 - link
Nope, this appears to be a reverse Wine translation layer. It takes linux syscalls and turns them into NT.The underlying filesystem will still be NTFS.
This is basically GNU tools on Windows kernel.
osxandwindows - Wednesday, March 30, 2016 - link
fuck no.I don't trust microsoft.
doggface - Wednesday, March 30, 2016 - link
Cool story bro.Daniel Egger - Wednesday, March 30, 2016 - link
As for the differences: cygwin has been around for ages and works pretty well despite feeling like an alien, however many of the differences you just mentioned also apply to OS X and yet it feels pretty Linuxish under the bonnet nowadays but obviously Apple wouldn't partner with Microsoft to give them the same edge...As for drawing more developers to Windows: good luck with that, enabling Linux/OS X/BSD/<you name it> "workflows" (basically only those relying on bash, which is a clear pointer to autoconf/automake) on Windows is only the smallest step of many. As long as the rest of the tools continue to suck this won't fly anywhere... And why use Windows natively if it is much simpler to crosscompile e.g. with MXE.
aryonoco - Wednesday, March 30, 2016 - link
Cygwin does not work well.Cygwin uses the ancient POSIX compatibility layer that's been around in Windows since NT 4.0, and presents all its own weird problems. Everything has to be ported to Cygwin, which is no easy task. Also, Cygwin is dog slow. Writing to a modern SSD at 10 MB/s is not particularly novel in 2016.
This is a very big deal, it allows running Linux binaries unmodified on Windows. No need to recompile anything, no need to port anything to another weird POSIX. All the Linux binaries that people know and use and are maintained well, on Windows.
This is an impressive bit of engineering. Sure NT has always had the ability to run different userspaces, and it did have a POSIX environment and and OS/2 environment for a while, but those provided source compatibility. Translating every Linux API syscall to NT? And doing so at native speeds? This is hugely impressive.
For the first time in a LONG time, I'm really excited about something in Windows. Heck for the first time in a long time, I might actually think about buying a Windows laptop next.
aIIergen - Wednesday, March 30, 2016 - link
It looks like the same idea as linuxulator which has been working for > 20 years on BSDs.aryonoco - Wednesday, March 30, 2016 - link
Yes indeed, it is very similar to the Linux compat layer that the BSDs have long provided.From a computer science perspective, this is nothing new. Back in the late 90s and early 2000s, there was a product called Win4Lin from NeTraverse which did the opposite of this, it translated Win 95 syscalls to the Linux kernel and allowed Windows binaries to be run "natively" on Linux. Problem was it only supported the Win 9X branch, and once the Windows userland moved to NT, it became obsolete.
It takes a fair amount of engineering to pull something like this off, but it is not novel from a programming point of view. It does mean that Microsoft now has to track the Linux kernel API to maintain compatibility, but that's fairly stable so it's a low-risk strategy. Still, in this age of virtualization and containerization, I did not expect to see something like this from Microsoft. Kudos to them.
Klimax - Thursday, March 31, 2016 - link
Sorry, but wrong. Cygwin does not use POSIX Subsystem. (Windows 8 dropped it, it implemented only older specification and had some severe limitations)Cygwin always reimplemented POSIX on WinAPI.
aryonoco - Thursday, March 31, 2016 - link
You are right, Cygwin is a Win32 implementation.It doesn't change the fact that it's dog slow.
Vatharian - Wednesday, March 30, 2016 - link
Ummm... Cygwin? Been around for years?lilkwarrior - Thursday, March 31, 2016 - link
This isn't the same thing; this is much, much betterKlimax - Thursday, March 31, 2016 - link
Hello POSIX Subsystem. Long time no see. Now we have fun....aryonoco - Thursday, March 31, 2016 - link
POSIX subsystem only provided source compatibility with Unix (and like all other versions of Unix, had its own peculiarities which meade porting software very difficult to it).This is binary compatibility, translating Linux kernel syscalls to to the NT kernel. Very different kettle of fish.