Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows Subsystem for Linux: The lost potential

jmmv.dev

Post reply on HN
Print view View original

151–160 of 250 posts

Re: Windows Subsystem for Linux: The lost potential

#151

Post by bootlooped »

electrotype wrote: post #139

I tend to agree with the article. What does WLS2 provides that a regular VM (VirtualBox for example) doesn't? Or a Docker container that I run with "C:" mounted as a volume?

Better performance, easier to use if you're just using command line stuff, first-party support. Docker's own docs state that it's better to run containers on the WSL2 backend than the old way (a hyper-v vm just for Docker).

Flip the question the other way: what does VirtualBox offer me that I'm not getting from WSL2? I just need Linux command line tools for software development. This feels like the best way to get them on Windows.

It's easy to imagine use-cases when a full blown VM are better; not my current use-cases though.

Re: Windows Subsystem for Linux: The lost potential

#152

Post by 1_player »

cbdumas wrote: post #53

I too was really sad to see WSL 1 be replaced by what seems to be just a built-in VM. One of the great things about WSL 1 is that I can run Linux tools on my laptop without the memory overhead of a VM. My laptop only has 8GB of ram which is not enough for Windows and a Linux VM to comfortably share, but plenty to run the Linux tooling I want under WSL 1. On my desktop with 16GB of ram I can just run Virtualbox. WSL 2…

While still being a VM, WSL2 works much better than a Virtualbox VM: boots in 1 second (!) on my machine, as attested by uptime and dmesg, has dynamic memory reclamation, out of the box file sharing through \\wsl$, VSCode integration.

Same technology, yeah, but much more ergonomic.

Re: Windows Subsystem for Linux: The lost potential

#154

Post by sfblah »

When working on Windows I often use the verion of bash which comes with git. It's obviously not at all the same as WSL, but it gives you a lot of the feel of using a Unix machine while working in windows. The command-line tools work properly, for example.

I see others are offering similar comments, so I'll stop there. Try bash; it's ok in many cases.

Re: Windows Subsystem for Linux: The lost potential

#155

Post by strunz »

sfblah wrote: post #154

When working on Windows I often use the verion of bash which comes with git. It's obviously not at all the same as WSL, but it gives you a lot of the feel of using a Unix machine while working in windows. The command-line tools work properly, for example. I see others are offering similar comments, so I'll stop there. Try bash; it's ok in many cases.

It's cool, but warning that it treats variables differently. For example if you run an EXE command-line tool which looks for Windows environment variables, it won't use the Bash environment variables. Probably not a huge deal, just a gotcha we've hit at my company which caused a lot of wasted debugging time.

Re: Windows Subsystem for Linux: The lost potential

#156

Post by naikrovek »

sedatk wrote: post #24
ralph87 wrote: post #9

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 b…

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 c…

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.

Re: Windows Subsystem for Linux: The lost potential

#157

Post by skissane »

mixmastamyk wrote: post #103
trilinearnz wrote: post #10

This is a really interesting article, and WSL 1 was a testament to Dave Cutler's vision for the NT architecture re: support for multiple operating environments (read 'Showstopper!' for more background). Also, as someone hacking with a custom OS kernel in their spare time, I found this quote illuminating when it comes to understanding the lower level: > A user-space process is a collection of binary instructions that…

It's a shame the author didn't mention the original POSIX and OS2 subsystems. I guess the idea didn't pan out and contributes to poor performance.

The OS/2 subsystem only ever emulated OS/2 1.x, it never emulated OS/2 2.x or later. That severely limited its usefulness. Also, it only supported text mode apps out of the box, and the GUI was only available from Microsoft as an add-on sold separately (which very few people bought)

There was never a huge amount of OS/2 software anyway. And a lot of what software was available for OS/2, also had native Windows versions, so why bother emulating the OS/2 version when you can just switch to the native app?

A lot of people ran OS/2 1.x because it was the basis of Microsoft's networking solution, Microsoft LAN Manager – which as well as being sold by Microsoft, was also sold in OEM versions from IBM, HP, 3Com, among others. But rather than trying to run OS/2-based LAN Manager under NT, people used NT's native implementation of the LAN Manager protocols (SMB File & Print)

I think the POSIX subsystem could have been a lot more successful if Microsoft had invested in it more. But I think Microsoft was worried about investing in it too much, because if UNIX software can run on Windows, a lot of developers might just write UNIX software only, not write to the native Win32 API, and then there would be less switching costs to move that software off Windows and on to UNIX or Linux.

What is different about WSL, is that by now POSIX has clearly won the battle for developer mindshare, and Microsoft has decided their best interests are to cooperate with it fully rather than continue in their prior hesitancy about it. But they've had 20+ years to watch it win in the market, and that's informed their change of heart.

Re: Windows Subsystem for Linux: The lost potential

#158

Post by Iwan-Zotow »

cspotrun79 wrote: post #36
blueflame7 wrote: post #8

Earlier quoted context omitted.

Even within Explore to mount a remote linux server over ssh?

why would you need that if you have the command line functionality already? Windows has shipped with sftp for a while now. about the only think missing is a stand alone ssh client on the windows side but for that there is putty.

ssh, sftp, scp are all there, part of W10 SSH package

Re: Windows Subsystem for Linux: The lost potential

#159

Post by johncolanduoni »

moron4hire wrote: post #108
alerighi wrote: post #106

Earlier quoted context omitted.

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…

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

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.

Re: Windows Subsystem for Linux: The lost potential

#160

Post by Iwan-Zotow »

lostmsu wrote: post #123
uberman wrote: post #54

Earlier quoted context omitted.

There is a native ssh client in windows 10. https://docs.microsoft.com/en-us/windows-server/administrati...

Now I want screen or tmux. Otherwise you can't really run anything on a remote Windows machine over SSH on spotty connections.

well, this thing sometimes works

https://docs.microsoft.com/en-us/windows/terminal/panes

Post reply on HN