A lot of resistance some will have to WSL will be old battle scars from Microsofts past behaviour. Microsoft have done a lot over the years to troll the Linux community. While many of the younger HN members will be familiar with the "new open source Microsoft" some of us oldies have had to endure IE breaking the web plus ActiveX / Silverlight and other MS web lockins. Comments like "open source is communism" from top MS execs. Fragmentation of Java (which eventually spawned into .NET but there were years of pain before .NET became a thing of beauty). To be honest more sins than i have time to list. So many of us are now cynical by default with regards to MS.
Take WSL for example, I'm sure their motives are just to encourage people away from Linux and OSX for sysadmin and dev workstations. I can see that strategy working for many people too. But at least with WSL, if they do decide to cripple it once they have the customer base then it's pretty trivial for users to switch away again (which was less doable with many of the other tech they've dominated the market place with).
So while the trolling remarks of the OP are clearly unconstructive, i can at least emphasise with why he feels the need to speak out against MS. He just did so in a pretty lousy way.
> at least with WSL, if they do decide to cripple it once they have the customer base then it's pretty trivial for users to switch away again
Now that they're embracing the typical Linux userland, I can't help but ponder if they'll try shifting to the extend+extinguish part later on. I guess old habits die hard, especially when you got burnt multiple times already, although I'm not cynical enough to think this would be all planned beforehand but more like at some point some exec would notice this as a strategic opportunity to seize.
That said they're certainly winning some Linux users back, and if anything, this may even help in getting some Windows people used to Unix and Bash, reducing the gap for them to try their hand at some Linux distro. All in all, cross-pollination is good both ways.
I also think their current strategy could be the one you describe. We're at the Embrace phase. It's not sure that Extend will follow but I wonder what it could look like. Maybe it will be something convenient you can do in Linux only if you're running it inside WSL. Given how Linux is used it should be something server side, Internet facing (no Active Directory, Exchange, SQL Server, those are Windows markets anyway). A bonus would be some compatibility tool to do that on native Linux too. If enough software is written to run for Linux+WSL and it gets deployed in production, then the Estinguish phase will be ready to kick in: deprecate the compatibility tool and hijack all the Linux market to Windows. The timescale for playing out these strategies is at least 10 years, so let's talk about it when approaching 2030.
If Microsoft is really thinking along those lines, a way it could fail is if Linux expands to other markets. That would make it hard to Extend to most of the use cases.
However what WSL is doing it to make those MacOS users that deploy to Linux consider moving back to Windows because there is a Linux subsystem there too. Actually, a real Linux instead of a look alike.
By the way: why did they named it Windows Subsystem for Linux instead of Linux Subsystem for Windows? It's Linux running inside Windows, not the other way around.
It's named like this because it is a subsytem of the NT kernel (hence the Windows subsystem part) that implements Linux system calls to run Linux applications (hence the for Linux part).
Naming it the other way around ie Linux for Windows would imply that the Linux kernel is involved which is actually not the case at all.
Also, they previously had a Subsystem for Unix (SFU/SUA), so they're being consistent with their naming. That was the old POSIX layer that included, IIRC, a shell script to wrap cl.exe to take gcc-like arguments, and you can get third-party compiled binaries of things like bash.
I'm not saying that those money are peanuts but it doesn't compare to what they were doing (are?) with software licenses. Maybe they plan to cannibalize the desktop with subscription services and Azure.
I see things they could do with a WSL+Azure integration but I don't want to give them the idea :-) Anyway, they are collectively smarter than me (and more focused on their businesses) so they'll already thought about that for sure. That's why I'm somewhat worried.
> A lot of resistance some will have to WSL will be old battle scars from Microsofts past behaviour.
I'm also not convinced they've changed at all when I see what they've done to things like skype, where they have somewhat of a monopoly (thanks to office).
Or more recently, Microsoft's refusal to remove "curl" from Powershell, where "curl" was an alias to a totally different Windows function that barely resembled curl.
IE4 was better than Netscape communicator but not significantly. Before (IE3 and below) things were a lot more even. However by IE4 MS had already won the browser wars. It was a fair while after that point when AJAX became a thing (and Netscape and Opera did support a competing API to XMLHttpRequest btw). The problem with IE was that it wasn't standards compliment, only ran on Windows desktop and Mac (even Windows CE didn't really have a decent working version of IE) and even with their lack of regard for the standards offer very little innovation compared to the 10 years they had leading the market. Think about how much the web advanced once Firefox and Chrome gained traction and how far behind IE quickly got left, then tell me that what Microsoft did for web was a positive thing.
Real Player and Flash were cross platform (albeit Flash outside of Windows was and still is garbage). ActiveX was Internet Explorer on Windows desktop only and Silverlight was only partially cross platform (parts of Silverlight was ported to OSX and only OSX so it's a bit of a stretch to even compliment Silverlight for being "partially" cross platform).
I'm wondering if you are misguided here - and what Microsoft is working on right now is "Bash on Windows" - I.E. The console environment that people want to interact with when writing quick scripts, connecting to remote servers, maybe running a little bit of a local web instance.
Speaking for myself, personally - if I want to run GNU/Linux software through the Linux ABI - I'm not going to be doing it on WSL - I'll do it on a VM or on a farm of VPS/EC2 instances somewhere. The attraction to me for WSL is the ability to have all my rich windows software, tools in the same environment that I'm connecting to those hosts from (which I normally do with OS X).
Note that the vast number of improvements (consoling, ping, vt100 support, launching windows apps from linux, etc...) in Creators Update are about improving the CLI/Shell experience for users.
Bash is merely a Unix shell, one of many. What you describe is the GNU/Linux userland.
They are working on people being able to execute unmodified Linux binaries on Windows machines through an Application Binary Interface that implements the Linux system calls and translates them into Windows system calls, among other things... and doing it in the most transparent way possible (not requiring specific builds of each software, like Cygwin).
This is the inverse operation of what WINE does.
No need to rush to downvote a comment that is actually correct.
Everyone you're replying to understands how WSL and UNIX shells work. The error is on your part because you keep misunderstanding that the Windows executable one runs to invoke WSL is literally
C:\Windows\System32\bash.exe
Sure, once you've started bash you can then probably switch to whichever shell you want afterwards (NOTE: I say that but I've not tested to see if other shells work). But to use your WINE example, the Windows Bash.exe PE is the equivalent executable to the wine ELF.
Now you are welcome to rant about how the WSL "invoker" should be isolated from the POSIX shell, but that's very different from the point you keep raising and thus keep getting down voted for.
When I say bash, I am referring to GNU bash, the shell that has existed for decades now on Linux, BSD, macOS, Solaris and an endless list of other operating systems.
I do not care if Microsoft couples their ABI and the shell and decides to call that "bash". GNU bash will continue to be what it has been for decades now.
I also do not care if a lot of people want to take the entire GNU/Linux userland and decide to call that "bash". That is not bash either, and will never be no matter how many people insist on it, not even Microsoft.
Finally, if Microsoft decided to couple bash with WSL, think that they went through the effort of replicating most Linux system calls. Having bash as a default shell is not a technical requirement on their part. Maybe now it will be, for backward compatibility reasons, but that's a different issue.
Then, you can downvote and insult all you want, that won't make you right.
Getting bash to run was a major milestone. Getting that application (which hooks into IO, process control, console output, devices, security, among many, many other things) is orders of magnitude more complex than getting something like awk running (and it still isn't 100% complete). I guess, from my perspective, the major deliverable for WSL was bash. You could have gotten hundreds of other subsystems in the LTP delivered, and dozen of the major products like nginx, cassandra, etc.. running - but until I could hop onto the system with bash, it wasn't an environment that I could interact with (as opposed to my programs).
There are many userland binaries that require far more system calls than bash. Take any general purpose programming language, like Python, Ruby or JavaScript on node as a simple example. Their libraries expose a lot of functionality that would finally translate into syscalls.
So no. I disagree that bash was a major final milestone.
In particular, check out this tidbit:
“Until you run Bash, no Linux process can run on your machine. As soon as you open Bash, you can choose to start any background services you want to have run. If you want to have MySQL or FSH or ssh or Postgres or Apache or whatever run, you can start them manually or autostart then with the .bashrc file,” Turner pointed out. “But as soon as you close the Bash console, we tear down any running Linux processes. So if you close the console window, you can no longer access your system via ssh, from your machine or any other.”
Whats interesting about this, is bash really plays a significant role in anchoring the entire windows subsystem for linux - more so than what you would normally expect out of merely a shell - to some degree, it is your user environment.
The limitation you are referring to is purely artificial, since WSL implements those system calls (they're required to implement bash itself) and I bet they are going to be fixing it soon.
I recommend you the following book: http://man7.org/tlpi , go to Chapter 24. kthx
I'm curious as to whether you realize that you've now taken so strong a position on this issue that you've blinded yourself to the evidence? I just gave you some information that showed that, the center of activity for Creators Edition is Bash. Bash is the only way that you can launch your linux subsystem on windows. Lots of work has been done on this Bash environment. It's entirely reasonable for Microsoft to say, "What's new in Bash/WSL and Windows Console" - as that's where they've done all the work. Bash is not just a Unix Shell in Microsoft's particular implementation - unlike every instance of Unix I've ever used (Starting with SunOs in 1993, but including zillions of iterations of Linux, OpenBSD, Solaris, etc...) - your shell on WSL is not just an entry into /etc/passwd, but instead is your operating environment - that, when it goes away, takes the entire process tree with it.
I kind of get what you are saying, that you are irked that Microsoft is trying to take some ownership of Bash, when it's really a GNU property - but, honestly, this is more like a temporary fork. Right now, for Anniversary Edition and Creators Edition - Bash is the center of gravity (along with the console environment - tons of awesome stuff there). And I agree with you, that this feels like a temporary hook, and that in the future, WSL will be able to run without Bash - and that will be a good (great!) thing - crontab! And then, Bash will hopefully just return to being what it was before - just a shell. (Perhaps with a few extra WSL hooks than vanilla GNU Bash - but we've already agreed that each implementation of Bash will have those hooks, so nothing new there.)
How about we both agree that Bash is a shell. Developed and Maintained by GNU. That is required by WSL right now to launch the linux subsystem, and therefore work by Microsoft on their Bash environment is important to WSL.
Stop adding noise/personal remarks and stick to relevant information.
> Bash is the only way that you can launch your linux subsystem on windows
For now. On Windows only. Bash has never been a requirement to run Linux software, they're not coupled in any way.
> Bash is not just a Unix Shell in Microsoft's particular implementation
Then it's no longer GNU bash. It's something else. Feel free to invite Microsoft to provide a new, non-ambiguous name for it. And then rename their binary: <something else>.exe so users like yourself don't get confused.
In addition, Microsoft should not couple the ABI with a particular shell. There are many shells and people should be able to select the one they prefer.
Finally, if WSL cannot run bash's unmodified Linux binary, then WSL is a leaky abstraction and not a true Linux ABI. In that case you are better off just running Linux from a VM for the time being.
Okay - you make some good points, and I'm coming around to seeing things your way. Note that the bash (the shell) that you are running inside WSL appears to be binary identical to a stock ubuntu distro - so from that perspective, the bash you are running turns out to be exactly GNU bash, totally unmodified.
shephard@singtest:~$ uname -a
Linux singtest 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
shephard@singtest:~$ ls -lart /bin/bash
-rwxr-xr-x 1 root root 1037528 Jun 24 2016 /bin/bash
shephard@singtest:~$
root@Skully:~# uname -a
Linux Skully 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
root@Skully:~# ls -lart /bin/bash
-rwxr-xr-x 1 root root 1037528 Jun 24 2016 /bin/bash
And once WSL has been fired up, you can run any shell you want to .
root@Skully:~# fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
Reading around the web - I note that Microsoft appears to be very careful about referring to "Bash/WSL" as a joint unit to refer to the Bash.exe component of WSL. Perhaps everyone on this thread (minus you and a few others) are the ones who are confused - perhaps the "Bash.exe" in Bash/WSL really is completely unrelated to "bash" the Bash shell? It may be the case that when I type "Bash.exe" from the start menu on Windows, the binary I'm running is completely unrelated to "bash" the linux shell - and this entire thing is a branding exercise. (as I think you've very patiently been trying to point out). Perhaps it would have made more sense to rename "Bash.exe" to "wsl.exe" - but then they wouldn't have been able to ride on Bash's branding...
It's kind of Ironic when the one person being downvoted to oblivion for several days turns out to be the only one correct. But at least you won over one person. I'll never refer to it as anything other than WSL - and correct people who think they are running Bash (the GNU shell) when they type "Bash.exe."
Fair enough. Hope you can un-downvote the ones you downvoted. While comparing binaries by size can help, I recommend comparing binaries by hashing them (e.g: sha1sum). Usually better in terms of security.
C:\Users\laumars>bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
The rest of the subsystem isn't called "bash", it's called "Windows System for Linux". It just happens that bash.exe on Windows contains the WSL hooks rather than being a straight port of GNU Bash.
Frankly bash across Linux, FreeBSD and Solaris will differ anyway due to differences in the way PTYs are registered, variations in supported signals and different syscalls (all issues I've ran into when writing my own cross-platform Linux/Unix shell by the way). So you'll find hundreds of compile-time conditions defined in Bash's source code which alter the behaviour of the outputted ELF (and I don't just mean your typical libc linker differences). So MS and Canonical integrating the WSL hooks into bash.exe isn't massively different enough for your argument to stand.
Linux, BSD, Solaris, etc. have significant differences among them, and the source code needs to be aware of them. Same with all crossplatform software.
But from the perspective of a Linux binary running on WSL, running on WSL should be the same as running on Linux. If bash is an exception to that, that seems more like a hack on Microsoft's part.
If they implemented the execve() syscall and others, starting whatever other user specified shell should not be problematic.
You need to reread this thread because I am literally the only person who entertained your poorly written arguments and spoke to you like you weren't a troll. Instead of insulting me and demanding compensation you really should be thanking me for being the only person who gave your opinion the time of day.
I wasn't the one who downvoted your comments. In fact quite the opposite as I actually upvoted your OP (I felt a little sorry for you) but now I wish I hadn't bothered.
And for what it's worth, your original argument was not that Bash.exe shouldn't include the WSL. You've just subtly inched your way to that conclusion after all the other complaints you made were directly debunked. I even threw you a lifeline a few comments earlier (as referenced in my previous post) and you argued that wasn't your point, yet now -somehow- it is? Jeez....
>So while the trolling remarks of the OP are clearly unconstructive, i can at least emphasise with why he feels the need to speak out against MS. He just did so in a pretty lousy way.
Just stay on topic and avoid personal attacks.
I have been consistently referring to GNU bash, Linux and Linux software interchangeably.
Creating confusion around those terms because is not in the best interest of the community of users of GNU/Linux.
Even if Microsoft, Windows and WSL never existed, GNU bash would continue to be what it is, which is: A Unix shell. Not a technical requirement to run Linux software.
typo: I have been consistently against referring to GNU bash, Linux and Linux software interchangeably.
Also against referring to GNU bash and bash.exe interchangeably. Or people trying to redefine what GNU bash is because of how it is distributed under Windows.
The problem is, that C:\Windows\System32\bash.exe has nothing whatsoever to do with bash, the GNU shell. They are entirely unrelated. C:\Windows\System32\bash.exe is the component which initiates the WSL subsystem. With cygwin, when you run bash.exe - you are literally running the bash shell compiled for windows. Once C:\Windows\System32\bash.exe starts up, it then launches bash - the GNU shell.
Take WSL for example, I'm sure their motives are just to encourage people away from Linux and OSX for sysadmin and dev workstations. I can see that strategy working for many people too. But at least with WSL, if they do decide to cripple it once they have the customer base then it's pretty trivial for users to switch away again (which was less doable with many of the other tech they've dominated the market place with).
So while the trolling remarks of the OP are clearly unconstructive, i can at least emphasise with why he feels the need to speak out against MS. He just did so in a pretty lousy way.