Beyond Bash: Microsoft Refines the Windows Subsystem for Linux
1–8 of 8 posts
Re: Beyond Bash: Microsoft Refines the Windows Subsystem for Linux
#2Interesting that Microsoft is so eager to support enough syscalls for non-GUI developers. But I wonder how much this increases the attack surface of both Windows and the WSL Linux.
Re: Beyond Bash: Microsoft Refines the Windows Subsystem for Linux
#3"the increasing number of developers considering a move from Mac OS because they find the MacBook Pro underpowered for their needs"
Why the need to insert anti Mac FUD into a technical article?
"via a pico driver with Microsoft’s clean room implementation of the Linux syscall interface."
Why clean room it, the kernel is GPL after all. This whole Linux-on-Windows strategy is nothing more than a ploy to slow down Linux adoption. Provide enough features to call it Linux without being actually being useful.
Re: Beyond Bash: Microsoft Refines the Windows Subsystem for Linux
#4"the increasing number of developers considering a move from Mac OS because they find the MacBook Pro underpowered for their needs" Why the need to insert anti Mac FUD into a technical article? "via a pico driver with Microsoft’s clean room implementation of the Linux syscall interface." Why clean room it, the kernel is GPL after all. This whole Linux-on-Windows strategy is nothing more than a ploy to slow down Linux…
All FUD aside, "developers looking for an alternative to the new MBP" is a pretty decent market to capture. I have no doubt that Microsoft are directing their efforts to try and take advantage of them.
Re: Beyond Bash: Microsoft Refines the Windows Subsystem for Linux
#5"the increasing number of developers considering a move from Mac OS because they find the MacBook Pro underpowered for their needs" Why the need to insert anti Mac FUD into a technical article? "via a pico driver with Microsoft’s clean room implementation of the Linux syscall interface." Why clean room it, the kernel is GPL after all. This whole Linux-on-Windows strategy is nothing more than a ploy to slow down Linux…
I think it makes a lot more sense to clean room it. Most (all?) of the functionality is already present in the Windows kernel, there just needs to be a Linux compatible API exposed.
The alternative is to... run two kernels? I doubt that's feasible in any form that doesn't resemble running a Linux VM.
Re: Beyond Bash: Microsoft Refines the Windows Subsystem for Linux
#6"the increasing number of developers considering a move from Mac OS because they find the MacBook Pro underpowered for their needs" Why the need to insert anti Mac FUD into a technical article? "via a pico driver with Microsoft’s clean room implementation of the Linux syscall interface." Why clean room it, the kernel is GPL after all. This whole Linux-on-Windows strategy is nothing more than a ploy to slow down Linux…
I think it makes a lot more sense to clean room it. Most (all?) of the functionality is already present in the Windows kernel, there just needs to be a Linux compatible API exposed. The alternative is to... run two kernels? I doubt that's feasible in any form that doesn't resemble running a Linux VM.
The NT kernel has had a POSIX subsystem since the beginning. I'm not sure whether WSL uses this though.
Re: Beyond Bash: Microsoft Refines the Windows Subsystem for Linux
#7Interesting that Microsoft is so eager to support enough syscalls for non-GUI developers. But I wonder how much this increases the attack surface of both Windows and the WSL Linux.
It may not be the only reason, but my thoughts from the start were that if this flushes out enough, getting Linux containers (docker) on windows in a native way could be a big win, and even bigger in Azure's space. I really liked the approach that Joyent took to getting Docker/Linux containers on their Solaris fork.
Re: Beyond Bash: Microsoft Refines the Windows Subsystem for Linux
#8Earlier quoted context omitted.
I think it makes a lot more sense to clean room it. Most (all?) of the functionality is already present in the Windows kernel, there just needs to be a Linux compatible API exposed. The alternative is to... run two kernels? I doubt that's feasible in any form that doesn't resemble running a Linux VM.
The NT kernel has had a POSIX subsystem since the beginning. I'm not sure whether WSL uses this though.
check this out: https://brianreiter.org/2010/08/24/the-sad-history-of-the-mi...