Comment by asveikau

Comment by asveikau 3 days ago

27 replies

View on Hacker News

The explanation they give is they need to put their trademark, Windows, before Linux. Sometimes they say this is advice from the legal department.

I still think they could fulfill that requirement and call it the "Windows Linux subsystem" or something, but what do I know?

Unrelated, but I think the WSL2 design is kind of stupid. It's just a VM. I think the WSL1 design, where it was a syscall layer, is a better call. But that was slower, IIRC chiefly because the NT filesystem syscalls are slower than Linux's VFS. Rather than improve that problem, they side-step it by running Linux in a VM.

cpgxiii 3 days ago

The design of WSL(1) makes more sense when you think of its original design goal of being a compatibility layer for Android apps. Android is "a Linux", but it is (1) a relatively unique one, and (2) everything between the Android kernel and Android apps really isolates the application layer from kernel-level details. Given this separation, it makes a lot of sense to leverage the existing NT flexibility and emulate a Linux kernel at the syscall layer. Sure, you'll have to patch some parts of the WSL(1) Android system components, but MS was already going to have to do that to work around Google-only components. In many ways, this route is no more complex than what Blackberry did to run Android apps atop their QNX-based OS.

But once you give up the specialization for Android and want WSL to be a "real Linux" (i.e. behave like a specific Ubuntu/Fedora/etc distribution) now you no longer can get away with being Linux-like, you have to be Linux (i.e. you need the syscall layer to directly mirror all kernel development and features). It's actually fairly impressive how much worked with WSL(1) given how different the internals were, but you didn't have to go that far to find tools/services/etc that just wouldn't work.

Instead, once you consider how long MS had been working on Hyper-V, and how interested they are in using it to apply additional security boundaries/isolation (e.g. VBS) within what outwardly appears to be a single Windows OS instance to the user, it makes a lot of sense to leverage that same approach to just run a real Linux kernel atop Hyper-V. In that world, you no longer have to match Linux kernel development, you just need to develop/maintain the kernel drivers used to interact with Hyper-V - and MS already had a lot of experience and need to do that given how much of Azure is running Linux VMs.

Reply View 4 replies
  • technofiend 2 days ago

    IO on many little files is dramatically faster in Linux on ext4 vs Windows thanks to NTFS' journaling overhead. So if you're doing development, you really want to do it inside wsl2.

    Reply View 3 replies
    • asveikau 19 hours ago

      I think it's more complicated just than NTFS's design.

      In my original comment I said that the difference is the Linux VFS for a reason. The slow part in NT is when you go from a filename to a handle. Doing things like caching lookups by name is, IIRC, the responsibility of the individual drivers. Linux does better at this by having a heavily optimized layer sitting between the filesystem driver and the caller. Doing tons of open(2)s is faster on Linux because of the overall kernel design.

      Reply View 0 replies
    • p_ing 2 days ago

      Journaling isn't the issue, small files go into the $MFT which is the fast-path. The issue is the file system filter overhead.

      Reply View 0 replies
kbolino 3 days ago

The bigger problem was how fast Linux evolves. Windows kernel development is glacial by comparison. Keeping up with every new thing in Linux was tantamount to maintaining a second operating system.

Reply View 7 replies
  • bayindirh 3 days ago

    IIRC, there was an article, whose author said that improving NT kernel without blessing from higher ups is even frowned upon.

    So making a better WSL on syscall layer, which NT kernel is designed for, is not only behind a technical effort wall, but also behind a big red tape.

    Reply View 1 reply
    • RedShift1 2 days ago

      That's a good thing. The kernel is supposed to be the most stable thing.

      Reply View 0 replies
  • duskwuff 2 days ago

    I'd argue that the breaking point was Docker. Running typical Linux userland applications was doable - and they did it - but making Docker work would have been effectively impossible, as it depends on a ton of highly Linux-specific systems (namespaces, cgroups, bind mounts, etc) with no direct Windows equivalents.

    Reply View 4 replies
    • pjmlp 2 days ago

      Windows has native support for containers.

      Reply View 3 replies
      • kbolino 2 days ago

        Windows containers are interesting. Windows--like most other operating systems--mediates interaction between applications and the operating system though libraries (specifically, user32.dll and kernel32.dll). Whereas, Linux provides a stable syscall ABI that applications can directly interact with. This makes Linux containers fairly insensitive to host kernel version, as long as they don't use experimental features and the host kernel isn't older than the stable features needed by the container processes.

        I would have expected Microsoft to address this issue in Windows containers by supplying the correct version of the system DLLs at runtime. However, it seems that they decided to bake them in at build time instead. This makes Windows containers similar to Linux containers but it could have made them quite kernel-version-sensitive. According to MSDN, newer kernels are able to run older images, implying to me that they've begun to stabilize the kernel interface, potentially enough to enable proper static binaries. See https://learn.microsoft.com/en-us/virtualization/windowscont...

        For the topic at hand, though, Windows containers run Windows software, and a lot of software that gets containerized never runs on Windows normally and so can't easily be containerized for that platform. Even when the language and libraries are cross-platform, the build process often isn't.

        Reply View 1 reply
        • pjmlp 2 days ago

          Windows containers have two execution models.

          In one, each container gets its own kernel copy, while the other one works like Linux containers, and indeed you need a recent version, as there were some issues doing that on older versions, which is yet another reason to be running Windows 11.

          Note that having kernel copy to go along the containers is also existing on Linux world, this is what advanced security models like Kata containers.

          There is plenty of Windows software on big corporations that will never be ported to Linux, and that is the golden use case for at least put them into containers.

          One such example are all the .NET Framework applications that will never be rewritten into modern .NET, or Windows Services (aka UNIX daemons).

          Reply View 0 replies
      • duskwuff 2 days ago

        Sure - and I assume that's how Docker for Windows works. But that's a long way from getting Docker for Linux to run on WSL1 - for that to work, WSL1 would need to implement details of the Docker implementation like overlay mounts (to pick an example at random). That suddenly starts looking a lot less like a compatibility layer and more like a reimplementation of parts of Linux.

        Reply View 0 replies
ronsor 3 days ago

Improving that problem probably would've been a massive undertaking. That aside, there's the problem that implementing kernel mechanics is a lot more than faking syscalls: the various types of namespaces, FUSE, random edge cases that applications do expect, kernel modules, etc. At the end of the day, users don't want to stumble into some weird compatibility issue because they're running not-quite-Linux; it's a better UX to just offer normal Linux with better integration.

The WSL2 design isn't stupid, it's practical. What I will give you is that it's not elegant in an "ivory tower of ideal computing" sense.

Reply View 6 replies
  • bitmasher9 3 days ago

    When people talk about improved compatibility or higher practicality I wonder why they don’t just run Linux on metal at that point. You can either run it on your laptop, or connect to a networked computer.

    Reply View 0 replies
  • Brian_K_White 3 days ago

    Can I even use a usb serial port yet after how many years? (Possibly by now but how long did it take, and does it actually work well?)

    It is stupid in that it's not really any kind of subsystem, it's just a vm. VMs have their uses, but it's basically just an app.

    The reason hardware such as my usb serial example (or any serial) worked on wsl1 was because it actually was a subsystem.

    Reply View 4 replies
    • beagle3 3 days ago

      Your serial might have worked, but your docker didn’t. (And someone else’s other drivers didn’t, and mmapping had ever-so-slightly different semantics causing rare and hard to reproduce issues).

      WSL2, on the whole, is much more compatible. If you want 100% Linux compatibility, just run Linux.

      Reply View 2 replies
      • Brian_K_White 2 days ago

        I do. That's why I didn't know the current answer to the question. But I use software that wants to talk to hardware, not just cloud software that might as well be on a vps.

        Reply View 1 reply
        • dwattttt 2 days ago

          Calling gcc (which runs entirely happily in WSL2) "cloud software that might as well be on a vps" is at the same time accurate and apparently insulting.

          Reply View 0 replies
tester756 2 days ago

>Unrelated, but I think the WSL2 design is kind of stupid

Yet in practice works very well

There's saying if something is stupid, but works, then it aint stupid

Reply View 1 reply
  • dvfjsdhgfv 2 days ago

    True, but I love the instant boot of WSL1 when I need to do something quickly. And, most of the time, if you don't do IO-heavy stuff, it works quite well.

    Reply View 0 replies
emmelaich 3 days ago

You can still use WSL1 if you want. (maybe you know this).

Reply View 0 replies
bee_rider 3 days ago

> I still think they could fulfill that requirement and call it the "Windows Linux subsystem" or something, but what do I know?

Your name is bizarrely better considering how small the difference is.

> The explanation they give is they need to put their trademark, Windows, before Linux. Sometimes they say this is advice from the legal department.

It feels like they have some strange internal naming policy. Maybe it is called the “Policy Product for Naming.”

Reply View 1 reply
  • grugagag 3 days ago

    Their naming is a serious problem that spreads confusion instead of clarity but what do they know, they’re like a headless chicken that has enough power to stay alive no matter what..

    Reply View 0 replies
setopt 2 days ago

Windows Subsystem for Linux Usage or something would have been clearer.

Reply View 1 reply