"This is a real native Bash Linux binary running on Windows itself. It's fast and lightweight and it's the real binaries. This is an genuine Ubuntu image on top of Windows with all the Linux tools I use like awk, sed, grep, vi, etc. It's fast and it's lightweight. The binaries are downloaded by you - using apt-get - just as on Linux, because it is Linux. You can apt-get and download other tools like Ruby, Redis, emacs, and on and on. This is brilliant for developers that use a diverse set of tools like me."
"This runs on 64-bit Windows and doesn't use virtual machines. Where does bash on Windows fit in to your life as a developer?
If you want to run Bash on Windows, you've historically had a few choices.
Cygwin - GNU command line utilities compiled for Win32 with great native Windows integration. But it's not Linux.
HyperV and Ubuntu - Run an entire Linux VM (dedicating x gigs of RAM, and x gigs of disk) and then remote into it (RDP, VNC, ssh)
Docker is also an option to run a Linux container, under a HyperV VM
Running bash on Windows hits in the sweet spot. It behaves like Linux because it executes real Linux binaries. Just hit the Windows Key and type bash.
What's next, RedHat on Server?
In case you've not noticed, this is a very, VERY different Microsoft, one I re-joined recently precisely to work on this very feature! :D
More questions: Will it be backported to Windows 8.1? How does it differ from CoLinux and andLinux?
because no one is forcing linux users to do anything. can you really not see the difference between giving an option to developers and "dragging linux users"
I'd rather have a home I have control over, or even trust in.
However, "Linux" is almost always a reference to GNU tools and the Linux Kernel. It may not be semantically accurate, but take that up with the same people that made literally mean both itself and its opposite.
Let's try the opposite. Say someone got Wine working to the point where it was very nearly, perfectly indistiguishable from Windows and they put up a blog post saying "Everything works just as it should under Windows, because it is Windows." Microsoft's lawyers would come around with a C&D, and calling them pedants wouldn't invalidate their case.
He could have said "it's just like Linux, right down to the kernel interface" or "Everything works just like Ubuntu, because the userland is Ubuntu". Succinct and correct. Precision matters.
Knowing this, what should we call it?
Windows Subsystem for Running POSIX + Linux Syscall API Compatible Userland Tools? WSRPLSACUMT? :)
I'm genuinely interested on what you all feel would be a good way to think about naming moving forward.
But there's a difference between "This is Ubuntu running on WSL" or "This is Ubuntu running on our Linux compatibility layer", and "This is Linux".
I did actually give this some thought, for what it's worth. There are problems with "GNU" in the name and problems with "Ubuntu" in the name.
But it seems to me that Microsoft has a naming scheme that it is perhaps unaware of. See https://news.ycombinator.com/item?id=11417059 . (-:
Except that isn't the opposite, it's an entirely different situation.
1) It isn't Windows. It's a complete rewrite of the Windows API's. That is not the same thing that's happening here.
2) A C&D isn't a case, it's a piece of paper (politely) asking you to do something. Calling something Windows and it actually being an infringement on Windows patents are entirely different issues.
> Precision matters.
In carefully crafted theoretical situations feigning as analogies to this situation? Sure. In the real world? Hardly.
Debian GNU/kFreeBSD is Debian, but it isn't Linux.
Mac OS X with GNU tools via MacPorts/Fink/Homebrew is OS X with a GNU userland, but it isn't Linux.
Windows 10 with an Ubuntu userland is Ubuntu, but it isn't Linux.
Linux is a kernel.
> A team of sharp developers at Microsoft has been hard at work adapting some Microsoft research technology to basically perform real time translation of Linux syscalls into Windows OS syscalls. Linux geeks can think of it sort of the inverse of "wine" -- Ubuntu binaries running natively in Windows.
You're getting confused with MinGW, which uses MSYS to build native Windows executables. They need MSYS (as a Cygwin-derived emulation layer) because tools like GCC or Bash expect the system to support POSIX APIs and have POSIX semantics-- for example, Windows has no equivalent to a POSIX fork() call. The code you're compiling under MinGW has no MSYS or Cygwin dependencies, but the compiler and tools themselves (gcc, bash, the linker, etc.) do.
Not the person you're replying to, but interesting ...
>tools like GCC or Bash expect the system to support POSIX APIs and have POSIX semantics-- for example, Windows has no equivalent to a POSIX fork() call.
So do Cygwin and/or MSYS emulate the fork() call on Windows? and if so, do you have any idea how that is done? Just interested, since I have a Unix background - not at deep OS level, but at app level and also at the level of the interface between apps and the OS (using system calls, etc.).
Yes. That's one thing we spent considerable engineering effort on in this first version of the Windows Subsystem for Linux: We implement fork in the Windows kernel, along with the other POSIX and Linux syscalls.
This allows us to build a very efficient fork() and expose it to the GNU/Ubuntu user-mode apps via the fork(syscall).
We'll be publishing more details on this very soon.
What does that mean?
That's why the child is allowed to do almost nothing:
the behavior is undefined if the process created by vfork()
either modifies any data other than a variable of type pid_t used to
store the return value from vfork(), or returns from the function in
which vfork() was called, or calls any other function before success‐
fully calling _exit(2) or one of the exec(3) family of functions.
So will this be only on Windows 10?
Cygwin does some pretty horrific hacks to emulate it. It basically creates a paused child running the same binary, fills in its memory, stores the register context of where it came from in a shared memory, and then resumes the child. The child on startup detects that it was forked, and then looks into shared memory to resume running at the place of the fork.
edit: It's even worse than I remembered: https://www.cygwin.com/faq.html#faq.api.fork
In fact the binaries, that are compiled with MinGW, link with MSVCRT by default (Microsoft Visual C Run-Time DLL). So no compatibility layer, and they don't rely on Cygwin.
In any way, for me, this is a great news. The fact was really hard to work with python/ruby/node/etc under windows and the fact I hate powershell were the two main things about why I work on a linux os all the time.
Yes; full, standard, repo access .
> With full access to all of Ubuntu user space
> Yes, that means apt, ssh, rsync, find, grep, awk, sed, sort, xargs, md5sum, gpg, curl, wget, apache, mysql, python, perl, ruby, php, gcc, tar, vim, emacs, diff, patch...
> And most of the tens of thousands binary packages available in the Ubuntu archives!
You might hate the terminal where PowerShell runs, but I don't think you hate Powershell.
I see a future where devs move to Windows due to Bash and stay due to PowerShell.
First, PS Remoting is terrible compared to SSH. Commands fail randomly on a small percentage of systems, and the only options to troubleshoot are to login manually to the remote system, and try a number of things, including rebooting the remote system (not very good for servers).
Second, debugging is terrible compared to bash - sure PowerShell ISE allows you to step through your code line by line, however, I don't have anything like "bash -x script.sh" which lets me see the actual execution and return code of every line of my scripts.
Third, bash has a much simpler way to chain output through multiple programs using pipes and treating input/output as simple text. PowerShell is a pseudo programming language with objects and other data types that just don't enable this type of chaining in the same simple and easily understandable way.
It took me weeks to write a PowerShell script that used PS Remoting to loop through a list of provided servers, install a service, set the RunAs user, start the service, create a secret file, and EFS encrypt that file as a specific user. I could have written the same script in hours using bash for Linux boxes. It would have been much more efficient by using tools like GNU parallel.
I'm not sure how anyone that's used both PowerShell and bash for any serious work could say PowerShell is better, unless they're a .NET developer and appreciate being able to blend .NET objects into their scripts, but to me, that just breaks the simple modular composability of the *nix philosphy.
I feel very comfortable getting a stream of data and treating it with sed, awk, grep and whatever; but once I worked with objects it feels much more data-oriented.
And please don't get me wrong, I've been in love with Bash since a Slackware CD fell on my hands in the 90s. I just was mind-blown by PS after making fun of it for years - just because the default terminal where it runs is less than great.
I guess this thread proves the point of bringing Bash to Windows: Different people, different uses, different needs and solution. And that makes me happy :)
(preferably for win7, because I run Linux at home and win7 is the most likely platform I may spend some time elsewhere)
I do appreciate, from all I've heard about PowerShell, it might be an interesting environment to try some scripting in. The actual shell/programming language can't be (much) worse than bash--I mean let's admit, bash is pretty ancient and therefore didn't have the advantages of progress in designing programming languages we have made in the past decade(s).
Of course, if you're too used to Bash and its paradigm there's a learning curve in PowerShell. Not steep, though :-)
The killer features for me are the objects and being able to seamlessly use C# libraries in my scripts.
However, I don't know if this is the case. I remember in the livestream Meyers saying that they will enable you to choose any shell you want "powershell, dos, bash, and more coming soon". If they just supported _any_ ubuntu binary natively, I don't know why he would've said "more coming soon"
How does it work without VM? I'm super curious!
The latter would be much more interesting to me, since what I really want out of "running linux on my desktop" is for it to actually act like the linux machines my code is targeting, and I'm dubious that a syscall layer will achieve that to the degree I want.
From what I can gather Microsoft is paying Canonical to help with a few user-mode bits and the Windows apt-get stuff uses the official Canonical sources.
As I said to him: "NT is the only major OS I know of that has always had personality subsystems. Cutler’s vision finally pays off after 3 decades of waiting"
But only because the Interix-derived POSIX subsytem was, and is, little-known and vastly underappreciated. Had it been better known, the payoff might have come a decade or more sooner. There are a fair number of questions being asked now, about the new Linux subsystem, where the answer is "No; but the old POSIX subsystem had that.".
* Does it support pseudo-terminals? No, according to the demonstration video; but the old POSIX subsystem did. (https://news.ycombinator.com/item?id=11415843)
* Does it let you kill Win32 processes? No; but the old POSIX subsystem did. (https://news.ycombinator.com/item?id=11415872)
* Does it support managing daemons? No; but the old POSIX subsystem did. (https://news.ycombinator.com/item?id=11416376)
* Does it support GUI programs? No (say the people behind it themselves, although I suspect that it could run X clients); but the old POSIX subsystem did. (https://news.ycombinator.com/item?id=11391961) (https://technet.microsoft.com/en-gb/library/bb463223.aspx)
Seeing her send SIGSTOP to a running MSWORD.EXE process and observe it stop updating its window in response to expose events was splendid. :-)
In what way is a "subsystem" different than a "library" or a "process" or a "driver" (if it runs in kernel space)?
Any process can use the native API. What's special about a "subsystem"?
I know that Dave Cutler was heavily involved in designing NT, and was earlier the same with DEC VMS. (Had read the book Inside Windows NT.)
But don't know what vision you refer to. Was it about the personality subsystems?
It is widely claimed and believed that when he moved with his team to MS that he reimplemented Mica as the NT kernel. http://www.textfiles.com/bitsavers/pdf/dec/prism/mica/
There is NO Windows "apt-get stuff" - it's just apt-get. From Ubuntu.
The linux module provides limited Linux ABI (application binary inter-
face) compatibility for userland applications. The module provides the
following significant facilities:
+o An image activator for correctly branded elf(5) executable images
+o Special signal handling for activated images
+o Linux to native system call translation
It is important to note that the Linux ABI support it not provided
through an emulator. Rather, a true (albeit limited) ABI implementation
"Mapping syscalls from one OS to another" was really just an example to give the OP an idea of how this sort of thing works without a VM.
Edit: Nevermind then
Cygwin and things like colinux exist on opposite ends of that awkward divide, but something officially supported by the OS could maybe straddle it better.
The Windows POSIX subsystem which shipped in NT 3.5.1 was a minimal implementation of POSIX syscall API plus a userland toolset. That was replaced with Interix which was renamed Services for Unix (SFU) which had a more comprehensive kernel implementation and more up to date userland. However that tech was not resurrected to build the Windows Subsystem for Linux (WSL).
Importantly, WSL doesn't ship with a distro - we download a genuine Ubuntu userland image at install-time and then run binaries within it.
So can we use WSL by itself and pick a different distro, if we'd rather use say Alpine or openSUSE or Arch's userland?
I, for one, would like to see it resurrected. It's exceedingly useful, and is one major reason that I am not, nor will be, using Windows 10. This new subsystem does not have the things that I use SFU/SFUA for. Nor does it have the BSD-style toolset of SFU/SFUA.
Seriously:shows an appreciation of where a lot of the workload for computer programmers is these days.
Sorry it's not recursive.
Follow up questions would be if it will support kernel-dependent utils like tcpdump, ifconfig, etc.
NT system calls are not exposed to userspace; only system-supplied dlls can use them. It is done by changing syscall codes for every build, so non-system app would never know, which syscall number to use.
That explains why Wine always seemed so buggy, though.
As long as Microsoft continues to disrespect the rights of users in regard to privacy, data-collection, data-sharing with unnamed sources, tracking, uncontrollable OS operations (updates, etc) - I will never go near it.
I expect some flack for my position... don't care. I find it especially offensive that ex-open source and ex-Linux users (working for Microsoft) have the audacity to come on here and try to sell this as a 'Linux on Windows' system when most of what makes Linux special (respect for the user) has been stripped away.
It's like giving a man who is dying of thirst sea water.
Most comments here appear to be positive and that's fine... whatever. Please don't sell your souls and the future of software technology for ease of use and abusive business practices. /rant
> Microsoft research technology to basically perform real time translation of Linux syscalls into Windows OS syscalls
This version is taking the native Ubuntu binaries and executing them directly against the Windows API via a real time translation later.
The difference is like playing a game using virtualization technology vs. WINE. As the complexity of the game increases, the former begins to slow down and break.
You don't have to be a fan of Microsoft but they deserve at least some credit.
Running the Linux kernel on Windows has been done before IIRC - coLinux?
Edit: thinking about it I'm not sure if I'm right. Or does Cygwin map the ping command to the Windows command?
It looks like Cygwin has a ping package, but it isn't something you'll get unless you specifically select it in the installer.
Windows Subsystem for Linux (WSL) which underpins Ubuntu on Windows is new Windows kernel infrastructure that exposes a LINUX-compatible syscall API layer to userland and a loader that binds the two.
This means you can run real, native, unmodified Linux command-line tools directly on Windows.
I've used it some on Windows earlier, and it worked pretty well. Might still available if anyone wants to try it. The only small issue I had was that the process to download it from the (AT&T) web site was slightly involved, for no good reason, as far as I could see. But not difficult.
I got a Mac primarily because of its linux side, but it is actually Linux.
This is still Windows, but with a Linux "side" to it? If I apt-get install redis, do I make it startup like I would in linux, or do I use windows services? In the screenshot there's a /mnt directory, is that behaving the same as it does in linux?
This is so confusing... but if it's legit, then I would actually look at switching back to windows.
No, it's not. OSX is literally UNIX. OSX is based off Darwin, which is based off BSD.
BSD was UNIX, yet neither of it's 2 prevalent derivatives (FreeBSD and OpenBSD) has applied for certification. They are classified as Unix-like; the same is true for any Linux distribution.
To some people, this may be semantics, but one of the reasons that drew me to OSX was the certification.
Also, large parts of the kernel are from BSD.
No part of Mac OS comes from Linux at all. Also, most of the standard tools are from BSD, not GNU.
Maybe you meant "it's a UNIX-like system" but those predate Linux by 30 years or so, and at any rate Windows + Cygwin was already a UNIX-like system to a similar extent, so that's not really relevant to what was accomplished here.
There is a distinction because you will notice much larger differences between Mac and [insert linux distro here] compared to linux distros to each other.
$ /usr/bin/cmp --version
cmp (GNU diffutils) 2.8.1
I'm genuinely very tired of OS X, which (to my perception at least) has gotten steadily worse with every version. I for one will be happy to switch.
Can't get node.js to run on your "Linux environment" and access a database running on windows? Good luck finding an answer for that on stackoverflow.
You'll have to target yet another environment for any app you develop. Will it be running on a Windows server? A Linux server? A server running "Windows with bash"?
Things like Node.js already run pretty well on Windows as it is, and MS is building native tooling in Node.js (e.g. their Azure CLI).
With this change, Microsoft is definitely going to encourage a lot of Surface adoption for geeks.
Stable USB stack would be nice as well. Ever since El Capitan, virtual machines I run off USB drive have been getting random I/O timeouts.
OS X tends to need quite a bit more memory than Win10. Win10 is as usable on 2 GB RAM as OS X on 4 GB. OS X graphics driver is also pretty slow, some 30% slower than on Windows. OpenGL support is pretty bad on OS X.
On Windows 10 side my biggest issues are unstable (or temporarily unavailable) RDP and bluetooth stereo audio stuttering. RDP color accuracy leaves also a lot to be desired.
And even though it is 3x3 MIMO, copying 20GB vm images is not something you want to do over wifi, so in the end I've got the Thunderbolt Ethernet adapter. Works like a charm, shorted the transfer by more than 10x.
SMB by itself never gave a problem (clean install of 11.0, then continuously updated to 11.4).
Transfer speed after overhead over 11ac 867 Mbps wifi is usually 400+ Mbps.
No packet loss (or at least it's below 0.1%).
Windows also offers a lot more customizations than OS X.
However, there are things I like about OS X also, like spaces and multi-touch trackpad support.
I use both on a daily basis.
I suspect RAM issues. OS X isn't great if - say - Chrome eats all the memory. And if the RAM itself isn't rock solid, you will get crashes.
A lot of issues went away when I installed 32GB.
This is a real problem for me as well. Not enough to make me want to ditch my Mac, but it's a real PITB.
I think part of my objections are that OS X used to be absolutely rock solid, around the Snow Leopard era. An entire release dedicated just to tuning up the OS! Unheard of now - I will never install a new version until the x.1 patch is out, there are always huge bugs.
I don't expect Windows to be rock solid, I just don't expect it to be any worse than OS X any more.
And thus MS has achieved their goal.
I have tried to figure out why I want a non-mac for my laptop and concluded I just like change... :) I was almost settled on that dell xps with ubuntu, but if the Surface Books get thunderbolt 3 and this before the autumn I am pretty sure I can't resist anymore...
If you plan on using the Linux environment and having it interact with the Windows environment you're going to have the same limitations that you would with a VM, OR you'll have to change your workflow because the way a program running under a Linux environment interacts with some windows service is going to be a completely new thing.
Will I be able to use a windows only service to interact with a command line program written in python running in the Linux layer? If I can't interact with the windows layer completely then it's very much like a VM or a container running inside a jail.
What happens when I install python or nodejs and stuff just doesn't work right? Like say I have a database running on windows and I want to interact with it with python. Will I have to rely in Windows making sure the compatibility layer always work?
The demos are VERY convincing. Basically everything works exactly like you would want it to work. It's exactly ubuntu and windows running through the same kernel at the same time.
Edit: yes, that is in fact exactly what the first link you gave says: The POSIX subsystem was added as the POSIX standard had become very prevalent in procurement contracts. [...] This original subsystem was, I think it's fair to say, deliberately crippled to make it not useful for any real-world applications. Applications using it had no network access and no GUI access, [...] SFU contains a full POSIX environment, with a Software development kit allowing applications to be written that have access to networking and GUI API's.
I worked at a place that developed a "Linux on Windows" thingy back in the Windows XP days. It was essentially like WINE. A user-mode Windows program would load the Linux binary into the Windows program's address space and execute it, trapping any attempts by the Linux code to issue system calls, and the Windows program would then service those system calls.
For non-GUI stuff this worked remarkably well. I was able to grab the binary for rpm off of my Red Hat system, and the then current Red Hat distribution disc, and install successfully almost all of the RPMs from the disc and have almost all of the non-GUI ones work.
I had expected big problems from the case-insensivite vs. case-sensitive filesystem issue, but in practice there were only a handful of things that ran into this. Mostly Perl stuff that used both "makefile" and "Makefile".
GUI stuff was another matter. We could run XFree86 under Cygwin, and then the Linux apps under our WINE-like program would work. However management was not keen on the idea of including Cygwin and XFree86 if we turned this thing into a project. Also, we wanted an X server that would fit in better with a mix of X and native Windows apps running at the same time.
I spent a while trying to write a Windows X server straight from the official specifications. I got as far as being able to get xcalc to display a window and all the controls to show up right, but weird things happened with events. Everything looked fine when I packet sniffed the communication. I still had not figured this out by the time management decided that this whole thing did not have enough of a commercial market to continue the project.
It is not built to support GUI desktops/apps. It is not built to run production Linux server workloads. It is not suitable for running micro-services or containerized environments.
Again - this is A COMMAND-LINE-ONLY DEVELOPER TOOLSET!
Apple stopped updating Bash in OSX when the upstream license changed from GPL2 to GPL3, I believe. (Fortunately, they keep the bundled zsh more up to date)
% uname -a; bash --version; zsh --version
Darwin hostname 15.4.0 Darwin Kernel Version 15.4.0:
Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)
Copyright (C) 2007 Free Software Foundation, Inc.
zsh 5.0.8 (x86_64-apple-darwin15.0)
Users with zsh as their default shell are a tiny minority.
The actual evidence from history of changing shells, from the Ubuntu and Debian worlds where they actually did make a change of shells (from Bourne Again to Debian Almquist) a few years ago, is that it doesn't drive people away in the first place, let alone away to Windows.
Even if one did a survey to make the latter not unsupported guesswork, one would have (if my experience of StackExchange is anything to go by) to account for all of those who answered that "My shell is Terminal.app." or "I have oh-my-zsh as my terminal.".
$> uname -a
Darwin K2523 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64
$> which bash
$> bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)
Copyright (C) 2007 Free Software Foundation, Inc.
I was also running into Haskell compilation problems that were fixed by running Ubuntu in a Vagrant environment but speed was slow. There isn't good NFS support on Windows either (there is some).
Windows still has a ways to go. I think this might make some Windows stuff easier to deal with, but I still prefer jobs where I can run Linux natively on my workstation.
This is the ISE in a default configuration https://imgur.com/xz9Kfpt
On the left just an open terminal, in the middle a script which can be edited and executed at any time with F5, and on the right all the powershell commands which could be either immediately executed or inserted into your script with ease.
Unless you need tab browsing that much, which you can get via addons, the ISE is one of the best "terminals" out there imho.
On my i5-3550 with 16 GB of RAM and an SSD it takes a couple seconds to start the first time and less than a second for subsequent times.
Both machines are running Windows 10.
Right now, the machine with the spinning rust is loading a bunch of files with an I/O priority of "background" because it just got booted into Windows; that might slow it down a bit because of the seek times and I don't know if Windows is willing to starve background I/O for seconds at a time to speed up interactive requests (I doubt it).
Update: once all the background preloading is done, PowerShell restarts in three seconds on the spinning-rust machine.
Long story short, I think getting an SSD will be the thing that makes PowerShell start acceptably fast.
Jeffrey Snover [MSFT]
Left click in fwvm, select xterm, window appears in less than my blink response time.
Seriously: I think I might pop Win10 on an old Dell i5 that came with Win7 and play with this.
As people have mentioned the biggest factor here is probably your hard drive since you are loading maybe couple of 100's of small files when you load the ISE.
What does this give you that you would not already have with cygwin? The latter installs .exe versions of the usual command line utils, and I'm almost certain ZSH and the others you speak of are included.
I do not understand the practical implications of this move by Canonical/MS other than PR - what's actually changing from a user/dev standpoint?
My only real problem with Cygwin is, that it misses a command-line package manager. If they could adopt pacman for package management like MSYS2 does, I'd be a happy camper.
edit: To deploy Cygwin based applications you need to get a commercial license from RedHat (if it's not FOSS). Which could be a deal-breaker.
There is babun (https://babun.github.io/). It is essentially a wrapper around cygwin and comes with a package manager.
Arch is certainly capable of updating pacman via pacman,and it's been a while but I'm pretty sure you can update apt/dpkg via the usual apt-get upgrade on Ubuntu
Not sure about X11 apps, but whatever.
Largely this makes running a special win32 build of redis for whatever dev you're doing unnecessary.
I'm currently running windows on this laptop, but I have a virtualbox instance running Lubuntu for doing any UNIX specific dev.
Ports and files are shared across windows and linux transparently, which means there's far less need for need for running+maintaining a separate developer's VM.
I personally think .NET is much worse than any of the more common web languages (even PHP or Perl) for the web. If I were writing a Windows application then I'd probably write it in .NET using Visual Studio, but not a web application.
As I said in my original comment "Different strokes.", you may like .NET. That's fine. It might be the right choice for you and the wrong one for me. I was more commenting that it was amazing to me that someone would think it was awesome because it sounds like the complete opposite to me.
I guess I should have asked what you find compelling about writing web applications in .NET.
I have issues with Microsoft's MVC (mostly that there is no official way of splitting it across several solutions and keeping working routing) but I've never found it overkill for enterprise-style webapp development.
We used MVC/Entity Framework. It works well as a RAD for the backend with full HTML/CSS/JS for the front end that we can get creative with. Reminds me a lot of Java development.
The MVC model itself is not overkill, sorry that sentence was not clear. I should know better than make contentious comments on HN that are going to spawn a bunch of aggressive responses when I'm trying to start my day.
You have not given any solid technical reason as to why ASP.NET is a bad framework. In my experiences, it's more or less as capable as Ruby on Rails, Clojure, Java, etc. You've stated it's overkill, meaning what exactly? Are you even aware of the changes being made to ASP.NET vNext? The dotnet cli tool? The only complaint you seem to have is that the tight coupling of ASP.NET to various Windows platforms is a little much for people who are used to Go or RoR.
But, you don't have to use mvc; there's Nancy or low-level Owin.
So why do people complain about MVC when there are other choices? Certainly not like in other platforms, but at least few good ones exists! Why judge whole platform because of one fx?
Similar like EF or Nhibernate. They are big and heavy and very slow if not used properly, but also there's Dapper, massive or simpleData.
.NET is overkill for web application development, IMHO. But I tend to eschew large frameworks in general. YMMV.
As far as being an "influencer"; do you see any links on my profile? Again, that's something other people find appealing, not me.
I think the HN intolerance towards Microsoft / zealousness for Apple is showing here. Certainly .NET isn't for everyone, but I don't think "is not a good web development framework" is justified. Check out http://nancyfx.org/ if you're looking for something more lightweight than the full ASP.NET / IIS stack.