Windows 10 Spring Update Bringing WSL Unix Sockets Support, OpenSSH / Curl / Tar Support

[polarathene]

Since Docker uses Hyper-V, if it supports using the GPU, so does Docker.

See my last comment responding to basically the same thing: https://www.phoronix.com/forums/foru...21#post1011821

What you say is true if using Docker for Windows(a Windows container), not Docker on Windows(Linux container via lightweight VM or perhaps WSL now too).

EDIT: My bad seems they've added Linux support on Docker for Windows too now. Still doesn't seem to be possible to use the GPU for such containers yet?

https://github.com/NVIDIA/nvidia-docker/issues/429

https://devtalk.nvidia.com/default/topic/1027743/linux/running-nvidia-gpu-in-ubuntu-docker-container-using-windows-10-docker-setup-and-windows-10-nvidia-drivers-/

https://www.reddit.com/r/MachineLearning/comments/75mg4q/d_is_it_still_impossible_to_have_a_linux_vm_for/

Last link is a response from the Hyper-V PM

> you need to be running Windows Server 2016, you need a server-grade GPU (consumer cards won't support it--yet, at least), the host needs to support SLAT

So yeah nah, not really an option any time soon.

[Vistaus]

Docker on Win10 is just HyperV. As HyperV on W10 goes, so does Docker.

There is a rumor in the press that Kali Linux subsystem will be in the Windows Store soon.

You've missed the news then as it's already available: http://news.softpedia.com/news/kali-...l-520076.shtml

[kpedersen]

It's not like people are going to stop using tar on linux because MS changes how it works on windows.

Well if they "extend" it i.e so tar can accept a url or something:

tar -xzf http://internal.web.server/myfile.tar.gz

Many scripts will start relying on that. And developers are lazy so it will go like this:

"Oh! The standard POSIX adhering tar doesn't support http. I forgot that. Oh well, rather than re-engineering all five of our build scripts, just install Windows on that server instead of Linux. Its easier."

Believe it or not, it is actually that easy to turn "Extend" into a weapon when it comes to small tools like tar. We have two servers at work running FreeBSD just because their version of tar supports extracting ISO 9660 files haha.
https://www.freebsd.org/cgi/man.cgi?tar(1)

Obviously it goes without saying "Embrace Extend Extinguish" shall never be forgotten lest we repeat the sins of our forefathers

[nslay]

WSL already has Unix socket support. This annoucement is about win32 now carrying support for basic Unix sockets, allowing direct communication between WSL and the rest of windows.

I wonder whether (or even how!) the Unix socket support on the Win32 side will actually support sending file descriptors to/from processes (the only definitive reason to use AF_UNIX/AF_LOCAL). The HANDLE stuff (even with _get_osfhandle) never seemed to play well with file descriptors stuff. Even sockets from winsock32 are somehow treated differently and are second class to the enormous collection of Win32 functions that operate on HANDLEs.

[lousticator]

IMHO, this is just a new sign of a "stealth move" towards a full replacement of the windows kernel (too expensive to maintain), in order to get "Windows UI" apps (thanks to .NET) on top of a genuine Linux kernel.

The same design than Android, but with a widely accepted look&feel + numerous apps that could run out of the box (or with a "legacy" support, thanks to a Microsoft-supported version of wine)

Just a logical cost-killing choice, slowly revealed to Windows-only users (that was clearly impossible in the Steve Balmer days)

It looks like a troll, but I'm convinced that all .NET and cloud changes introduced by Satya Nadella are going toward this simplified model

[lousticator]

IMHO, this is another stealth sign of the upcoming replacement of the "monster" windows kernel (expensive to maintain), in order to get Windows-UI apps (thanks to .NET libs) on top of a genuine Linux kernel (much cheaper than investing on a big close-source desktop-oriented kernel which requires changes for mobility and IoT).

It would be the same design than Android, but with a classical look&feel and a bunch of apps working out of the box, plus compatibility libs for legacy apps (helping the wine community to reach a 100% compatibility is simple when you have the original sources...).

OK, I know it looks like a troll, but I'm convinced that Satya Nadella's past decisions on .NET and cloud are part of this major "cost-killer" change for windows itself.

[lousticator]

IMHO, this is another stealth sign of the upcoming replacement of the "monster" windows kernel (expensive to maintain), in order to get Windows-UI apps (thanks to .NET libs) on top of a genuine Linux kernel (much cheaper than investing on a big close-source desktop-oriented kernel which requires changes for mobility and IoT).

It would be the same design than Android, but with a classical look&feel and a bunch of apps working out of the box, plus compatibility libs for legacy apps (helping the wine community to reach a 100% compatibility is simple when you have the original sources...).

OK, I know it looks like a troll, but I'm convinced that Satya Nadella's past decisions on .NET and cloud are part of this major "cost-killer" change for windows itself.

[dragorth]

Here is a sample from MS of a simple win32 server using this API. Go here to see the full details, and limitations of the Windows code. ( It details various permissions setups, and the designed behavoir.)

 [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]// Create a server AF_UNIX socket [/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]#define SERVER_ADDRESS “c:\unix\server.sock”[/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]SOCKADDR_UN ServerAddress = {0};[/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]Server = socket(AF_UNIX, SOCK_STREAM, 0);[/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"] [/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]// Bind the socket to a path. [/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]ServerAddress.sun_family = AF_UNIX;[/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]strcpy(ServerAddress.sun_path, SERVER_ADDRESS);[/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]bind(Server, &ServerAddress, sizeof(ServerAddress));[/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"] [/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]// Accept a connection. [/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]listen(Server, 5);[/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]Accepted = accept(Server, ….);[/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"] [/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
  [TABLE="class: highlight tab-size js-file-line-container"]
 	 		[TR]
 			[TD="class: blob-code blob-code-inner js-file-line"]// Send and receive data on the accepted socket. [/TD]
 		[/TR]
 		[TR]
 		[/TR]
 	 [/TABLE]
 // Shutdown and close the connection.

[nslay]

Here is a sample from MS of a simple win32 server using this API. Go here to see the full details, and limitations of the Windows code. ( It details various permissions setups, and the designed behavoir.)

 [TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]// Create a server AF_UNIX socket [/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]#define SERVER_ADDRESS “c:\unix\server.sock”[/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]SOCKADDR_UN ServerAddress = {0};[/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]Server = socket(AF_UNIX, SOCK_STREAM, 0);[/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"] [/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]// Bind the socket to a path. [/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]ServerAddress.sun_family = AF_UNIX;[/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]strcpy(ServerAddress.sun_path, SERVER_ADDRESS);[/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]bind(Server, &ServerAddress, sizeof(ServerAddress));[/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"] [/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]// Accept a connection. [/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]listen(Server, 5);[/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]Accepted = accept(Server, ….);[/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"] [/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
[TABLE="class: highlight tab-size js-file-line-container"]
[TR]
[TD="class: blob-code blob-code-inner js-file-line"]// Send and receive data on the accepted socket. [/TD]
[/TR]
[TR]
[/TR]
[/TABLE]
// Shutdown and close the connection.

That's a terrible example. You could do all the same with AF_INET. It doesn't do the one special thing that AF_UNIX/AF_LOCAL can do.

Check out "Control Messages" section on AF_UNIX:

https://www.freebsd.org/cgi/man.cgi?query=unix

That is unbelievably sketchy stuff that it can do. One process opens a file, sends the descriptor to a completely different process that can use the descriptor with file operations as if it had opened the file itself.

You could make some weird stuff. Like a daemon that can update without dropping connections. The daemon could exec a new version of itself and transfer over all its open files and state. Or even said daemon could be made to recover from crashes like that (within reason). It opens up all sorts of strange possibilities.

But see, win32 has an extensive API for HANDLEs... not file descriptors. How does this work with HANDLE? And it certainly seems to treat socket descriptors (from winsock32) differently than other kinds of files it can open (unlike Unix).

[cybertraveler]

That's a terrible example. You could do all the same with AF_INET. It doesn't do the one special thing that AF_UNIX/AF_LOCAL can do.

Check out "Control Messages" section on AF_UNIX:

https://www.freebsd.org/cgi/man.cgi?query=unix

That is unbelievably sketchy stuff that it can do. One process opens a file, sends the descriptor to a completely different process that can use the descriptor with file operations as if it had opened the file itself.

You could make some weird stuff. Like a daemon that can update without dropping connections. The daemon could exec a new version of itself and transfer over all its open files and state. Or even said daemon could be made to recover from crashes like that (within reason). It opens up all sorts of strange possibilities.

I didn't know that this was possible. Is it considered bad practise? How is it sketchy?