> In an ideal world, Windows should replace its entire NT underpinnings and either build their own BSD-inspired infrastructure (like Darwin) or create their own Linux distro using off-the-shelf Linux kernel as the main driver (probably can't because of GPL).<p>Why? Is a 'BSD-inspired infrastructure' or Linux the absolute best, or even significantly better? Is an OS monoculture a good thing?<p>> Apple had its miracle in the turn of the century, and OS X and iOS are terrific OSes. Best of the breed.<p>The user-facing portion is, but there are significant problems with some core features (semaphores, forking being very slow, file system notifications, HFS).<p>Also, for a fair comparison you should run the test suite inside a vboxfs mount.
> In Linux distros, every binary is compiled against very specific library headers such as the kernel itself, Glibc and many others. Whenever one of those change, all binaries must be recompiled to run.<p>This is wrong. Only kernel modules are compiled against kernel headers, and for userland programs the kernel is binary-compatible since ever.<p>Which is not to say that random binaries run bare on random systems, but this is a cultural rather than a technical problem (package managers insisting on having only one version of libraries, ignorance of the soname system). But with enough effort you can always get binaries to run on a system, provided you can get ahold of the libraries it expects, up to and including glibc.<p>>Which is why having source code available is so important<p>Back to front. The reason for the current situation is it's <i>expected</i> that the source code is available, so there's no incentive to provide stability for binaries. Why bother? It's gonna be recompiled soon <i>anyway</i>.
> In an ideal world, Windows should replace its entire NT underpinnings and either build their own BSD-inspired infrastructure (like Darwin) or create their own Linux distro using off-the-shelf Linux kernel as the main driver (probably can't because of GPL).<p>No, no! This is the exact opposite of the ideal world. What we need is for the NT kernel to stay, and for Win32 to get replaced.<p>Look, people from the Linux world can have trouble admitting this, but NT is a really good kernel. Better than Linux in some ways- not all ways, but some. The shittiness of Windows mostly comes from Win32. <i>That's</i> what should go away, and WSL is taking the first steps in that direction, even if Microsoft isn't planning on "going all the way" with it.
He incorrectly assumes there's some kind of file system emulation going on. There's not, WSL just runs on top of NTFS directly (NTFS doesn't have those pesky restrictions Win32 imposes).<p>Fact of the matter is, the file system has _always_ been a sore spot on Windows. It has known to be slow for decades and Microsoft engineers have flat out stated that it's not affecting their bottom line, so they have no incentive on changing that.
For WSL to be perfect (for me), it would also have to have better integration with the native filesystem. This whole business where the WSL filesystem is a separate thing, hidden away in the user's AppData folder, that you can't write to using Windows tools, is a significant drawback. I dunno, I guess I don't quite get who WSL is supposed to be for. The author of this article presents it as an alternative to running Linux in a VM. Which, OK, maybe that's exactly what it's intended to be. But I still wish that MS would include something like Hamilton C Shell as a built-in part of Windows. I.e. a unixy shell that provides unixy tools, and the ability to compose them, but where the tools are designed to mesh well with the rest of Windows.
>In an ideal world, Windows should replace its entire NT underpinnings and either build their own BSD-inspired infrastructure (like Darwin) or create their own Linux distro using off-the-shelf Linux kernel as the main driver (probably can't because of GPL).<p>In an ideal world, Windows NT stays, but Win32 is demoted to be just one of the subsystems the NT kernel supports.
> My ideal setup is actually a MacBook Pro. But I am forcing myself to live out of the Apple ecosystems, and it hurts.<p>Why? In all of the digressions I would like to read about this is a big one. I have been considering the same. The only Apple product I have left is a MBP. There are soooo many choices on the PC side of things. The paradox of choice hits hard when looking at; Samsung, Acer, ASUS, Lenovo, Dell, and HP. Some $700 models have the same specs as $1500 Mac's with touch screens and pen support.
Benchmarks were not made properly: there's no warmup, no multiple runs, etc
There are number of things, that would go wrong with it: cold caches, unloaded shared libraries, that might be already in memory in full Linux system in VM, etc<p>Also I should mention, that native Linux build might be optimized for ext2 or whatever as opposed to NTFS.
I agree with the author on quite a few things, but not the main point.<p>First thing that bothered me: He was bothered by the need to `sudo /etc/init.d/PostgreSQL start` to start up Postgres every boot. Yeah, that's annoying, but easily mitigated by running Postgres (and MySQL and any other service you need) in the Windows layer. Postgres installs just fine in Windows, and uses the Windows service system, which has gone basically unchanged for decades, versus Linux with like 3 service management systems.<p>But the main thing is that his main objection is that his test suite is about half as fast as it should be. This is honestly not a big deal to me, and I do Rails full-time as well. IMO, even the fastest run of his test suite at 2 minutes is still way too slow to run regularly. If I was working on that app, and I've worked on many with test suites many times slower than that, I would have already switched to running a limited part of it that tested what I was actually working on. I stick to about a 10-second max for tests that I run routinely while working. If it's longer than that, I'll run a smaller set that's under that, and run the full suite maybe once before pushing, or just let the CI server run it. I have to figure the number of people for who that kind of slow-down is a deal-breaker is pretty low.