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

31–40 of 250 posts

Re: Windows Subsystem for Linux: The lost potential

#31

Post by rbanffy »

hapless wrote: post #30
rbanffy wrote: post #18

Earlier quoted context omitted.

MacOS X is not a new version of MacOS 9 - it's renamed OPENSTEP with a MacOS X theme and some parts replaced. It's also very different from most Unixes in that it has a Mach microkernel with a BSD coat of paint. It almost has more in common with NT than it has with Linux. Before that, MacOS had (AFAIK - never seen it myself) the MPW environment that had a Unix-like shell. And A/UX.

I don't think it's accurate to call it a "BSD coat of paint." Practically an entire BSD kernel is run as a single "server" in Mach. In Apple's open source release, a majority of the XNU kernel code lies in the "bsd" subdirectory -- Apple's heavily patched 4.3BSD / 4.4BSD / FreeBSD hybrid. Originally the idea was that having most of a BSD kernel running inside Mach would make it easy for researchers to run tools on th…

Fair enough. It's a load-bearing, rad-shielding, armored, and money-saving coat of paint ;-)

Re: Windows Subsystem for Linux: The lost potential

#32

Post by TimTheTinker »

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…

That leaves out the fact that the kernel scheduler does in fact issue timed interrupts to all kernel and userspace code running on a given core, except for "critical sections" (where one or more locks are held).

That being said, the scheduler is so reliable and so seamless that one need hardly ever worry about it unless a particular block of code must not be interrupted, usually for parts of parallel/multithreaded code that have shared memory or other resources, or sections within the kernel or scheduler itself.

More info on the current Linux scheduler here: https://www.kernel.org/doc/html/latest/scheduler/sched-desig...

Check out the code here, if you're brave: https://github.com/torvalds/linux/blob/master/kernel/sched/f...

Re: Windows Subsystem for Linux: The lost potential

#33

Post by nix0n »

rbanffy wrote: post #14

If you want a Linux-like environment on Windows that can see and be seen from the Windows side, there is Cygwin. It's not as deeply integrated as WSL1, nor has binary compatibility (you'll have to get binaries compiled for it or compile them yourself) but last time I checked (Windows 7, IIRC) it did the job.

I can confirm Cygwin works with 10.

Its default package manager includes most of the standard POSIX tools.

I've used it a lot for on-Windows/for-Windows development, but always as a complement to native Windows tools.

Re: Windows Subsystem for Linux: The lost potential

#34

Post by hapless »

rbanffy wrote: post #26
hapless wrote: post #22

Earlier quoted context omitted.

The original POSIX subsystem was not very useful -- a minimal set of system calls, plus a Microsoft re-branded MKS Toolkit to provide shells and utilities. Microsoft ended up buying Interix, who offered a much more pleasant UNIX-on-Windows setup. That was supported for many years as "SFU" and later "SUA" SUA was still a pretty weird UNIX though. PE-COFF binaries, and a linker that wasn't 100% GNU compatible, and a lo…

On XP and 7 (and 8, perhaps) I used Cygwin to have a Unix-like environment. Does it still work on Windows 10? I remember I could call Windows programs from it and manipulate Windows files.

Cygwin is a very different approach.

SFU/SUA lived in kernel space -- they implemented a new set of system calls alongside win32. Binaries for SFU/SUA could not be executed on a system without SFU/SUA configured, because the kernel subsystem would be absent. (I also don't believe you could call win32 from SUA, but my memory is foggy.)

Cygwin and MSYS are attempts to map UNIX semantics onto windows system calls, to varying degrees of success.

Re: Windows Subsystem for Linux: The lost potential

#35

Post by devit »

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…

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)

Re: Windows Subsystem for Linux: The lost potential

#36

Post by cspotrun79 »

blueflame7 wrote: post #8
Iwan-Zotow wrote: post #3

Earlier quoted context omitted.

but it is included, as well as scp

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.

Re: Windows Subsystem for Linux: The lost potential

#37

Post by adzm »

rbanffy wrote: post #26
hapless wrote: post #22

Earlier quoted context omitted.

The original POSIX subsystem was not very useful -- a minimal set of system calls, plus a Microsoft re-branded MKS Toolkit to provide shells and utilities. Microsoft ended up buying Interix, who offered a much more pleasant UNIX-on-Windows setup. That was supported for many years as "SFU" and later "SUA" SUA was still a pretty weird UNIX though. PE-COFF binaries, and a linker that wasn't 100% GNU compatible, and a lo…

On XP and 7 (and 8, perhaps) I used Cygwin to have a Unix-like environment. Does it still work on Windows 10? I remember I could call Windows programs from it and manipulate Windows files.

Cygwin is definitely still around, but most people are using msys2/mingw and its bash prompt nowadays, especially with Git for Windows making it nearly ubiquitous.

Re: Windows Subsystem for Linux: The lost potential

#38

Post by rbanffy »

nix0n wrote: post #33
rbanffy wrote: post #14

If you want a Linux-like environment on Windows that can see and be seen from the Windows side, there is Cygwin. It's not as deeply integrated as WSL1, nor has binary compatibility (you'll have to get binaries compiled for it or compile them yourself) but last time I checked (Windows 7, IIRC) it did the job.

I can confirm Cygwin works with 10. Its default package manager includes most of the standard POSIX tools. I've used it a lot for on-Windows/for-Windows development, but always as a complement to native Windows tools.

This is great news. It offers a lot of what the author wants (except the speed of WSL2).

I would expect it to be less-complete than WSL1 (it looks like Linux, until you look it from up close) but faster, because it doesn't try as hard to be a Linux.

Re: Windows Subsystem for Linux: The lost potential

#39

Post by rbanffy »

hapless wrote: post #34
rbanffy wrote: post #26

Earlier quoted context omitted.

On XP and 7 (and 8, perhaps) I used Cygwin to have a Unix-like environment. Does it still work on Windows 10? I remember I could call Windows programs from it and manipulate Windows files.

Cygwin is a very different approach. SFU/SUA lived in kernel space -- they implemented a new set of system calls alongside win32. Binaries for SFU/SUA could not be executed on a system without SFU/SUA configured, because the kernel subsystem would be absent. (I also don't believe you could call win32 from SUA, but my memory is foggy.) Cygwin and MSYS are attempts to map UNIX semantics onto windows system calls, to va…

True, but it has some of the features the author mentions he would like from WSL1 (such as the bi-directional visibility), and, being open-source, if they really want it, they can always add it.

Re: Windows Subsystem for Linux: The lost potential

#40

Post by whoisburbansky »

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…

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