[ralph87]

Contra opinion: the VM option reduced the service interface between Windows and Linux to a single kernel implementation and a few drivers, rather than every possible userspace program ever written. It's an amazing and obvious trade off. My inner architecture astronaut appreciates all the ideas in this post, but I've been trying to kill that guy for over a decade now. The bottom line is WSLv1 design SUCKED precisely because it tried to cross-breed 2 extremely complex semantically incompatible systems.

Example: Linux local filesystem performance mostly derives from the dentry cache. That cache keeps a parsed representation of whatever the filesystem knows appears on disk. The dentry cache is crucial to pretty much any filesystem system call that does not already involve an open file, and IIRC many that also do. Problem is, that same cache in WSL must be subverted because Linux is not the only thing that can mutate the NTFS filesystem - any Windows program could as well. This one fundamentally unfixable problem alone is probably 80% the reason WSL1 IO perf sucked - because the design absolutely required it.

Solutions are rip out a core piece of kernel functionality, and in the process basically taking over ownership and maintenance for ALL code anywhere in the kernel assuming the existence of said cache, engineer something that is somehow better, and support this in perpetuity, including any semantic mismatches that turn up much later that were never designed for

The idea of merged ps output where Windows binaries would show up in the Linux /proc. How would you even begin to implement that without confusing EVERY process management tool ever written that interfaced with /proc? What about /proc/.../environ? On UNIX that has no character set. On Windows it is Unicode.

A trillion problems like this made WSL1 a beautiful nightmare. Glad it was tried and from watching the tickets, that team bled heroically trying to make it all work, but ultimately, I'm also glad it's gone, because the replacement is infinitely easier to engineer, maintain, and use, and that team earns its quarterly bonus much more easily. Everyone wins, except the astronauts, but as experience teaches us they never do.

[sedatk]

I agree with the sentiment but, some scenarios have become orders of magnitude more complicated on WSL2 like connecting to a daemon on Windows or vice versa. I understand clear cut security boundaries and separate network interfaces, but it's extremely hard to get them running smoothly now. Everything was on localhost on WSL1.

Memory usage has also gone bonkers with the VM approach, causing unnecessary overhead for casual users who don't need performance.

[GordonS]

> some scenarios have become orders of magnitude more complicated on WSL2 like connecting to a daemon on Windows or vice versa

This is about my only issue with WSL2, but it's a big one. Perhaps worse than this being a problem is that Microsoft don't seem to be providing any solutions - there are various GitHub issues about it, with non-Microsoft ransoms being the ones providing workarounds (but these depend on your environment - I haven't found any way to get this working myself!).

WSL1 was very ambitious. AFAIK, the main reason for shelving it's approach was filesystem performance. While it was indeed slower than native/VM, I personally never found it troublesome outside of artificial benchmarking. For the vast majority of use cases, WSL1 worked well, with Docker being the only real thing missing, IMO.

[Gene_Parmesan]

Running an npm install for an app of moderate complexity on WSL1 was such a painful experience that it turned me off of using the service for work dev entirely. Now with WSL2 it's much better, and I use it daily to the point where I have done away with my dual boot. (I still keep around a Linux notebook for edge cases.)

Obviously this is only re: fs perf, I can't speak to your other issues which do seem quite challenging. But I can definitely understand why they would have seen fs perf as a priority.

[month13]

FYI to any WSL2 users, in it's migrated configuration the WSL VM can request as much RAM as it needs, but has no means to free this back. There's an option to use .wslconfig to specify a limit.

https://github.com/microsoft/WSL/issues/4166

[9HZZRfNlpR]

My problem was that the ram was never released back when I didn't use it anymore and it started to kill windows itself. Had to hard limit it from the link you provided.

[blahyawnblah]

Does "wsl --shutdown" work?

[petters]

Yes

[selectodude]

WSL1 hasn't gone away for those who prefer it. But we're talking about an extra gigabyte. It's still cheaper than a full VM.

[1996]

It's even cheaper to only use what you need with msys2!

bash inside mintty gives me all I need, with minimal overhead.

Eventually, I'd like to see bash inside Windows Terminal made easily available - complete that with busybox, and you cover 90% of the Linux usecases without having to download anything (a bit like how starting Terminal.app offers most of what you need on MacOS)

Add an option to install packages using msys2/pacman for the power users, and I believe most people would not waste time (or disk space, or ram) playing with WSL1 or WSL2 just to run the one thing they may need.

[shawnz]

What makes you think the overhead between Cygwin/msys2 and WSL 1 would really be so great? They are both just translation layers after all.

[1996]

WSL1 tries to do too much. WSL2 tries to do even more.

msys2 mostly cares about running your textmode software.

For example, someone talked about processes. Here's all that I see in msys2:

# ps xwau

      PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND

      480     479     480      18796  pty1      197611 14:13:13 /usr/bin/bash

      479       1     479      16872  ?         197611 14:13:12 /usr/bin/mintty

     1118     480    1118      16496  pty1      197611 17:00:32 /usr/bin/ps

Most of the time, I don't need to access Windows processes - and if I do, data can be exchanged through a file.

[shawnz]

WSL1 also doesn't show windows proceses in 'ps', only the WSL processes. For example:

    shawnz@ShawnsPC:/mnt/c/Users/shawn$ ps xwau
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    root         1  0.0  0.0   8936   184 ?        Ssl  Nov17   0:00 /init
    root         6  0.0  0.0   8936    96 tty1     Ss   Nov17   0:00 /init
    shawnz       7  0.0  0.0  18588  2708 tty1     S    Nov17   0:00 -bash
    shawnz     252  0.0  0.0  18880  1984 tty1     R    18:04   0:00 ps xwau

[utxaa]

main draw for wsl2 for my team was IO performance. how is git on huge projects under msys2?

[shawnz]

It's clear that they are not enthusiastic about delivering new features to WSL1. Consider how WSL2 now exclusively features CUDA support, Wayland support, loop mounts, Docker, etc.

[Macha]

Docker support is precisely the sort of feature that would have required significantly more work to support in WSL1 than WSL2.

[shawnz]

Yes, admittedly loop mounts and Docker were an easy add for WSL 2 and would have been significantly more complicated for WSL 1.

[pjmlp]

Docker can also make use of Windows containers, and that is probably easier when everything is running on top of Hyper-V, as type 1 hypervisor.

[peteri]

Docker works fine with WSL1, I don't think I can use WSL2 at work as we're waiting on the next LTS version of Windows.

[shawnz]

Docker can't be hosted on WSL1. You can use the Docker client on WSL1 to communicate with a Docker host running on WSL2 or Hyper-V, though (which is how Docker Desktop works)

[sedatk]

I think WSL1 is there for transitional purposes and will be thrown away eventually. It was already incomplete, it didn't support forwarding any ICMP packets other than ping, so traceroute didn't work for example. I don't expect it to stay as an option for long.

[ASalazarMX]

At work we develop on Windows virtual machines, and WSL1 won't run on a VM. Fortunately WSL2 does, so at least I can enjoy Linux tooling I sorely missed.

[shawnz]

Interesting, I would expect the opposite problem since WSL1 doesn't use virtualisation in any way. Do you have more details about the error you experienced?

[ASalazarMX]

Unfortunately I tried WSL1, didn't work, and left it at that for months. When WSL2 was out, it just worked and I had forgotten by then what kind of error WSL1 gave me.

I can only recall it was a dialog box, not a crash, and that it had to do about virtualization.

[naikrovek]

In WSL 2 the nameserver is the Windows host OS. That's how you get the IP of the host if that's what you're talking about.

    export WINHOST=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}')

Because the Linux VM in WSL 2 is a "different" computer, mostly, according to Windows, there may be firewall trouble, I suppose.

[pjmlp]

Windows itself is a different computer, because Hyper-V is a type 1 hypervisor.

[1_player]

> connecting to a daemon in Windows

That doesn't seem impossible to implement. Can't you connect to some port on your gateway to access the host? Even if you currently can't, it still seems pretty easy to implement in the grand scale of things, than trying to make WSL1 work.

I'd imagine it is in some todo list somewhere in Microsoft

[whoisburbansky]

I apologize if I'm missing something here, but if casual users don't care about performance, what's the overhead here?

[B1FF_PSUVM]

Example: on WSL1 I could cheaply run Linux CS labwork including valgrind checks etc. - with less resources and much snappier than with VirtualBox VMs

I'm not confident about diving into WSL2.

[whoisburbansky]

I've had surprisingly good results running that sort of thing under WSL2. Pure CPU workloads actually work pretty well, and in my experience valgrind has mostly been CPU intensive?

[neurostimulant]

IIRC WSL 2 use 50% of your memory in Windows, or 8GB (whichever is smaller) by default.

[chaostheory]

I have 32 GB. Hardware is cheap for Windows. imo That's one of its main perks vs Apple

[ASalazarMX]

Is that an upper bound? My Ubuntu 20.04 console sessions on WSL2 consume a couple tens of Mb.

[neurostimulant]

The individual process inside the vm might not consume much, but the vm itself might reserve some GBs of memory. Try looking at how much memory `vmmem` process used in task manager.

[acqq]

Also:

https://www.reddit.com/r/bashonubuntuonwindows/comments/d8x7...

"So, I was copying a 8GB file to my Debian home folder using Windows Explorer, via $wsl network. The copy process made my CPU's fan runs like a jetplane, and it stop copying when at 95%, then I opened up Task Manager and saw this.

even after it finish copying, Vmmem process still hold 13GB RAM and not release any. Why? I have to shutdown WSL after copy a big file?

Answer:

Very normal but annoying issue. ... The only solutions are:

a) a kernel change by MS to limit the amount WSL2 can cache b) disable to caching ( nocache ) c) Put a limit on the WSL hyper-v VM

Not sure what or how MS will try to solve this issue... WSL1 did not have this issue, because it shared the main system memory, because it was just a layer around the NT kernel."

[ASalazarMX]

I can't find that process in my system, nor a significant difference in physical RAM usage before and after starting Ubuntu in WSL2. Digging a little it seems like memory is dynamically allocated and reclaimed when freed. I'm not defending WSL2, just trying to understand how is it supposed to consume 8GB of my 16Gb of RAM.

https://devblogs.microsoft.com/commandline/memory-reclaim-in...

[Karunamon]

Look for a 'vmmemory' entry in your process list, it'll likely be in the hundreds of megs, if not a gig or so.

[ASalazarMX]

I don't have that process while running WSL2 in my machine. I have vm-agent and vm-agent-daemon, but I'm using a virtual desktop, so this might or not be related to WSL2. Both of these processes consume less than 10 Mb combined. In my other comment [0] I referenced a link from Microsoft that says RAM is dynamically allocated and reclaimed when freed.

0. https://news.ycombinator.com/item?id=25161769

[whoisburbansky]

This hasn't been my experience, but sure, even if memory consumption is higher, for most applications where Windows users are going to use WSL, additional memory is incredibly cheap compared to the dev overhead of trying to boot into a Linux environment and switching back and forth.

[bostonsre]

Memory and cpu limits are configurable for wsl. You can cap your vm to whatever portion of your machine that you want.

[alerighi]

Correct, but... this is not WSL. This is a VM.

Let's see this from the opposite point of view: WSL1 is to WSL2 what WINE is to a VM running Windows. Two completely different approaches.

The thing that would have allowed the WSL1 to do was to really integrate between Windows and Linux: imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command. Imagine sending a signal to a Linux process from a Windows process. Or imagine accessing physical hardware from the Linux subsystem. With the WSL2 is impossible to even use a serial port!

WSL1 had performance problems. That thing about the filesystem performance could have been the occasion to optimize NTFS and even to add to the NT kernel the support for other filesystem, natively. Or why not add to the NT kernel other Linux functionality, to make them available both in the Linux and Windows subsystems.

Of course not everything would have been possible to map on the NT kernel. That is fine. But for most application really the WSL1 was usable.

Maybe the real problem with the WSL was only having called it "Widnows subsystem for Linux". They should really have made WSP: Windows Subsystem for POSIX. Drop the binary compatibility with Linux requirement and just make it an environment in which you can compile code that uses the POSIX API and interface with Windows. Not having binary compatibility with Linux is not a big deal, thing about it but is what macOS does and nobody seems to care, and users would have created a package manager just like there is brew in macOS to easily install software.

[jasonkester]

imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command.

But that's not most of us want to do with WSL. We just want to run the team's React app with its rube goldberg npm monstrosity that falls over when you try to run it on windows.

That use case covers 90% of us. No need to ask for anything more.

[TeMPOraL]

This is how our industry goes to crap. Repeatedly pruning things that 90% of the current userbase doesn't use over time give you a thoroughly useless product. I mean, do it 7 times, and you've already lost 50% of your audience. If you target 80% cutoff, you're down to 20% of the users now.

I personally do want it from WSL. Hell, 90% of my use of WSL is like this - I run Emacs on my work machine under WSL, where it feels at home. I use it to drive Windows-side cmake and Visual Studio compiler, piping output back to Emacs. Because I can, it works, and it's a much nicer working experience than any app could give me.

[userbinator]

Not having binary compatibility with Linux is not a big deal

But it is, because there is actually lots of proprietary software available on Linux as binary-only --- many of it very specialised and expensive --- and Microsoft wants to be able to run that too.

[moron4hire]

Windows Subsystem for POSIX was already tried. It didn't take off.

[johncolanduoni]

It was a hack to get around a US regulation about government procurement requiring POSIX support. So I think tried is a very strong word, it was never intended to be remotely useful.

[josephcsible]

Isn't the only reason that it didn't take off because it was so incomplete?

[sgerenser]

Incomplete and nobody really knew it existed.

[zerkten]

> That thing about the filesystem performance could have been the occasion to optimize NTFS and even to add to the NT kernel the support for other filesystem, natively.

I doubt that would be feasible given how important backwards compatibility is for Microsoft's business. WSL1 seemed like a huge effort on its own, so changing one of the most critical OS features would be a little ambitious.

[utxaa]

> imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command.

?? we do this all day long on WSL2.

[mook]

> imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command.

Actually for that special case WSL2 works. I'm currently experimenting with `sshd -i` on WSL2; not sure why it doesn't work on Ubuntu 20.04 but does on OpenSUSE 15.2…

[wahern]

Your point about the dentry cache seems like a non-sequitur. The cache isn't the bottleneck; the bottleneck is that NTFS is a crappy filesystem.

Yes, I've read this comment: https://github.com/microsoft/WSL/issues/873#issuecomment-425...

The argument about Windows not having a single, central dentry cache doesn't hold water. For one thing, there's no reason to think that a two-level cache would significantly decrease performance. More importantly, the fact that on Windows most VFS work occurs in the filesystem driver itself only proves that Windows could have implemented an EXT4 driver with better dentry and other semantics and permitted WSL1 environments to keep most of its files on an EXT4 volume, which is what happens with WSL2, anyhow.

WSL1 could have been better in every way. It would have required them to track a moving target, but they already accomplished semantic parity with seemingly minimal resources. Improving performance was certainly possible, and keeping up would have required significantly less work on its own. At the end of the day, I think the reason WSL1 was canned is obvious: the decision to ship WSL1 was probably accidental. Why accidental? Because anyone with the slightest business acumen would realize that a WSL1 environment with feature and performance parity to open source Linux would mean there'd be little reason to target Windows' native environment at all for new software development. And while Microsoft has done relatively well for itself with Azure and other ventures, its revenue still principally derives from Windows and Office, and the last thing Microsoft needs is to accelerate movement away from those products.

WSL2 means that Microsoft can keep its Linux environment a second-class citizen without being blamed for it, while still providing all the convenience necessary for doing Linux server application development locally. Integration with the native Windows environment will be handicapped by design and excused as an insurmountable consequence of a VM architecture. For example, with WSL1 and some obvious and straight-forward improvements it would have been trivial to run a Linux-built Electron app with identical performance, responsiveness, and behavior (not to mention look & feel, given the web-like UI). With WSL2 Microsoft will likely only ever provide GUI integration over RDP, which will never have the same responsiveness (not because it's theoretically impossible, but because nobody would ever demand it, and in any event it would require tremendously more effort than the comparable WSL1 approach).

[for_xyz]

> the bottleneck is that NTFS is a crappy filesystem.

Care to explain why do you think NTFS is crap?

From my experience it's usually bad assumptions about files under windows and every application or library tries to stick to posix interface when dealing with files (open, read/write, close) which tends to block for longer periods on windows than on linux counterparts which results in significant perfomance loss .

Linux first software will always outperform windows implementation and Windows first software will outperform Linux implementations unless you provide separate code paths to properly handle underlying OS architecture and assumptions.

On Windows closing the file handle is extremely costly operation due AV checks and file content indexing [1]

[1] https://www.youtube.com/watch?v=qbKGw8MQ0i8

[jmnicolas]

> Care to explain why do you think NTFS is crap?

I don't know if it's crap but it's much much slower than EXT4.

I remember reading a comment here that Windows in a VM on a Linux host was faster than bare metal.

Probably not true but I decided to make a test. I have a .net core app that insert data in a sqlite db (the resulting db is about 300 GB).

So I benchmarked this app on Linux (it was previously running on Windows) and IIRC it ran about 4 times faster.

[eitland]

An interesting observation I did was that even Hello World is about 100x faster on Linux than on Windows.

In my Linux VM I had to use the time command to even have an idea of how long it took, as it seemed to return immediately. I think 5-15ms but it already a while ago.

On the Windows machine where the Linux VM ran it took several hundred ms.

[for_xyz]

Which VM software did you use under windows?

[eitland]

Probably VirtualBox, could have been Hyper-V.

[m_mueller]

so what's the 'Windows way' then? keeping a file open forever and let it lock out other programs from using that file? I'm starting to get an idea why Windows is getting on my nerves so much with file locks....

[pjmlp]

Here is the thing, UNIX is the strange dude with advisory file locks, every other multiuser OS does the right thing to avoid file corruption.

[for_xyz]

> so what's the 'Windows way' then?

Using either memory mapped files of overlapped io (IOCP).

It's tricky to use when you want to write the content since you must preallocate the file before you start with the writing. Appending to file just doesn't work under NT kernel since WriteFile blocks even if you use overlapped io.

Devs just need different mentality when it comes to Windows programming compared to Linux. Due the fact that everything under NT kernel is operated asynchronously you'll have to adapt your code to such concept. Meanwhile under Linux you had no other alternative for nearly 30 years (io_uring and friends) so if you wanted to be portable with minimum OS specific code then you had to implement things in synchronous way or write two separate code paths for each OS.

Guess which one is used in practice.

[mehrdadn]

You can just use FILE_SHARE_WRITE if you don't want to lock out other programs...

[VBprogrammer]

If I know one thing about files it's that any fix beginning with "You can just..." is probably wrong.

https://danluu.com/file-consistency/

[mehrdadn]

I didn't recommend you do this, I just said it's there if you really want to.

[mehrdadn]

This is not due to NTFS. (And NTFS is not crap either.)

Try it on another file system if you don't believe me.

[acqq]

NTFS on Windows was indeed always significantly slower when doing a lot of file operations. It was noticeable even long before WSL existed: NTFS and the whole infrastructure connected to it has by design bigger maintenance cost for every opening of the file, for example. That's undeniable. One can say that NTFS could have maybe been implemented faster on some other system (with less hooks etc), but NTFS on Windows is provably slower for the file operations people do every day on Linux, that's a simple fact. Like working with big source repositories containing a lot of files (git, node.js). The people who decided to make WSL2 faster for Linux programs achieved the speedup by going full VM. I would also prefer that they worked on NTFS on Windows long enough until the file operations become faster for everybody, but it didn't happen.

That's one of the lost opportunities that the original article laments about.

Edit: a reply to dataflow’s "try your operations on another file system" answer: I don't have to, I remember: there was a time when people used FAT formatted media much more than today -- and NTFS was slower than FAT too, under the same Windows, on the same hardware, without installing anything from third parties. It can be that on Windows 10 FAT got to be comparably slow, but in earlier times, on slower machines, FAT was visibly faster compared to NTFS. But NTFS was more robust to failures, and I preferred using NTFS for anything that is not temporary. I admit that the whole Windows infrastructure around what we consider purely "a filesystem" is also a serious part of the problem, by design. And as I wrote, it's a lost opportunity that the bottlenecks weren't identified and the changes made to the benefit of everything on some future Windows.

[mehrdadn]

Again: try your operations on another file system, then tell me it's NTFS that's slow.

It's not NTFS that's slow at opening files. It's the I/O subsystem. You'll see the slowness with other file systems too.

[for_xyz]

This is the correct answer. Myth that NTFS is slow should already go away.

You can already run windows on top of BTRFS if you want but it'll be painfully slow compared to linux [1].

https://twitter.com/NTDEV_/status/1327358814891470850 https://github.com/maharmstone/quibble

[acqq]

Note: I've explicitly said: "NTFS on Windows" and "NTFS and the whole infrastructure connected to it". Also: "NTFS was slower than FAT" was true for years. I have no experience with BTRFS, but that doesn't prove anything without knowing more details (the overhead introduced to make it work). So... it's both NTFS and the Windows "subsystems."

[ralph87]

> The argument about Windows not having a single, central dentry cache doesn't hold water

This was more about cache coherency, and it's not an argument, it's a trait shared by every other Linux-over-X implementation (UML, coLinux). It is fundamental to solving a problem users want - seamless integration, i.e. no opaque ext4 blob. Why doubt the reasons given by Microsoft, when they match observations not just for WSL but every other system in the same class?

[brendangregg]

Good points; in addition, I can only imagine the headache of trying to support the latest eBPF, io_uring, WireGuard, and other advanced kernel features in WSL1. I imagine a lot of newer features would return ENOSUPP from the kernel, so WSL1 basically becomes a weird fork of an old Linux kernel. (Weird because it lacks a large community, and old because the ENOSUPP's downgrade what's available.)

In WSL2 everything should work (depending on the CONFIG options and how much Microsoft has changed).

[j0057]

NTFS performance leaves much to be desired on Windows too, it really hurts for workloads dealing with lots of small files, such as programming.

[jhallenworld]

I was wondering if Wine on Ubuntu is faster than Windows native. I found this OSBench near the end of this page (look for "Test:Create Files"):

https://www.phoronix.com/scan.php?page=article&item=wine-ubu...

Ubuntu native is much faster. It's odd that Wine is so slow.. I wonder why?

[userbinator]

Linux and Unix in general seems to love huge writeback caching, which is great for speed but horrible for consistency and reliability to power failure and such; on the other hand, Windows flushes the caches more often, providing greater reliability but without as much speed.

That's been my experience, in any case; doing lots of small file operations barely causes any disk activity in Linux, but far more in Windows. Moreover, abruptly cutting power in the middle of that would likely result in far more writes lost on Linux than on Windows.

[spacenick88]

Linux/Unix just trust that if you want something persisted with certainty you'll do an fsync, if you do it will absolutely guarantee you're not losing that. It will absolutely make sure that your filesystem doesn't get corrupted by a power loss but if you didn't fsync your write you had no place believing it was persisted.

Doing that IMHO matches real world use much better. If I do a compile and get a power outage I don't care if some object files get lost. If I do an INSERT in a DB I do care a lot but the DB knows that and will fsync before telling me it succeeded. So making sync explicit gives you both great performance and flexibility.

[userbinator]

Doing that IMHO matches real world use much better. If I do a compile and get a power outage I don't care if some object files get lost.

The real world use is someone working on a document, using Save periodically, and expecting whatever was last saved to survive the next outage, not some arbitrarily old version.

In other words, Windows implicitly fsync's often.

[kabes]

What are the trillion other problems? Honest question, some I heard this a lot, but in reality I only ever saw people complain about the speed of the filesystem. So that would just mean 1 (hard) thing to fix.

[ralph87]

The network stack integration was less than transparent too. Random places all over the system where e.g. a magical ioctl() just didn't work properly. Who really wants to spend their life reimplementing every last baroque detail of that stuff?

[utxaa]

not just the dentry cache:

https://github.com/microsoft/WSL/issues/873#issuecomment-425...

[devit]

The actual advantage of working on something like WSL1 is that it would ensure that the NT kernel is as capable as the Linux kernel (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels).

For instance, the complaints about I/O performance are because the NT kernel has a worse implementation, so they should have improved it for both Win32 and Linux apps instead of giving up.

(your reasoning about the dentry cache makes no sense though since such a cache would be implemented by the NT kernel and certainly not by WSL1, so there's no difference between Linux and Windows programs)

[jcranmer]

> (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels)

That is a coffee-spewing statement. Linux generally has a reputation of approaching new features by coming late to the party, seeing the mistakes everyone else made in the feature, and then implementing it somehow even more poorly than everybody else.

An example of a particularly bad Linux subsystem is ptrace, which interacts poorly with threads, relies on signals (itself a bit of a mess of a feature), and is notorious for all the races you have to do to actually properly set up a debugger. The Windows debugger API is much simpler, and even includes some features I'd love to have in Linux instead (hello, CreateRemoteThread!). I was going to write to the parent comment that implementing ptrace to let you run gdb (or, worse, rr!) in WSL1 would have been something that every NT kernel programmer would have "NOPE"d at because the impedance mismatch is just that high.

[saagarjha]

I mean, it's entirely possible to implement ptrace if you spend enough time doing it, it will just be complicated and the performance will likely be not that great. (But yes, it's a pretty bad API.)

[hapless]

As I understand it, it's not really possible to "improve" Win32 I/O performance -- both the fundamental I/O APIs and the NTFS on-disk storage format make high performance infeasible.

Not without either abandoning all extant FS drivers, or abandoning NTFS compatibility, anyway.

Edit: Here are the WSL 1.x's team members original comments on this subject. It sounds like a deeply intractable problem.

https://github.com/microsoft/WSL/issues/873#issuecomment-424...

https://github.com/microsoft/WSL/issues/873#issuecomment-425...

The second link explains why a dentry cache just isn't feasible.

The short version is that the NT IO APIs seem to have been very, very ill-considered. It's just not possible to make it fast. Even win32 operations are extremely slow, so win32 applications go out of their way to avoid doing any file I/O. Linux applications were not written with those constraints in mind.

[dblohm7]

Amusingly enough, I just watched a talk about this topic earlier today:

https://www.youtube.com/watch?v=qbKGw8MQ0i8

[meddlepal]

> Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels

Citation needed.

[tannhaeuser]

> Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels

Another interpretation is that Linux has been trying to re-implement Unix for 30 years, when the point of Unix in 1970 was a simple portable operating system that can be coded in like half a year.

[CJefferson]

I find IO on windows is fine, the problem with WSL1 was that the standard windows model doesn't line up well with Linux (fairly fundamental things like in Linux you can delete open files, which you can't do in Windows).

You couldn't switch Windows to a more linux-like model, it would break all existing windows programs.

[cpuguy83]

You can delete open files on Windows, but you need the right option (FILE_SHARE_DELETE).