←back to thread

Microsoft and Canonical partner to bring Ubuntu to Windows 10

(www.zdnet.com)
535 points raddad | 2 comments | 30 Mar 16 11:12 UTC | HN request time: 0.404s | source
Show context
hobs ◴[30 Mar 16 16:36 UTC] No.11390553[source]▶
Some additional details from Scott Hanselman:

http://www.hanselman.com/blog/DevelopersCanRunBashShellAndUs...

"This is a real native Bash Linux binary running on Windows itself. It's fast and lightweight and it's the real binaries. This is an genuine Ubuntu image on top of Windows with all the Linux tools I use like awk, sed, grep, vi, etc. It's fast and it's lightweight. The binaries are downloaded by you - using apt-get - just as on Linux, because it is Linux. You can apt-get and download other tools like Ruby, Redis, emacs, and on and on. This is brilliant for developers that use a diverse set of tools like me."

"This runs on 64-bit Windows and doesn't use virtual machines. Where does bash on Windows fit in to your life as a developer?

If you want to run Bash on Windows, you've historically had a few choices.

Cygwin - GNU command line utilities compiled for Win32 with great native Windows integration. But it's not Linux. HyperV and Ubuntu - Run an entire Linux VM (dedicating x gigs of RAM, and x gigs of disk) and then remote into it (RDP, VNC, ssh) Docker is also an option to run a Linux container, under a HyperV VM Running bash on Windows hits in the sweet spot. It behaves like Linux because it executes real Linux binaries. Just hit the Windows Key and type bash. "

replies(11): >>11390574 #>>11390626 #>>11390693 #>>11390705 #>>11390731 #>>11390748 #>>11390890 #>>11391364 #>>11392443 #>>11393237 #>>11402098 #
reidrac ◴[30 Mar 16 17:04 UTC] No.11390890[source]▶
MSYS is not Cygwin and IMHO is way better. Yes, is not Linux, but is a native binary without emulation (translation?) layer. It's been around for ages, before I did cross-compiling from Linux to Windows, that's what I used in Windows.

http://www.mingw.org/wiki/msys

replies(1): >>11390961 #
JonathonW ◴[30 Mar 16 17:11 UTC] No.11390961[source]▶
MSYS and MSYS2 actually are Cygwin-- the original MSYS being a (horribly out of date) fork of Cygwin that never really pulled much from upstream, and MSYS2 attempting to track upstream Cygwin more closely.

You're getting confused with MinGW, which uses MSYS to build native Windows executables. They need MSYS (as a Cygwin-derived emulation layer) because tools like GCC or Bash expect the system to support POSIX APIs and have POSIX semantics-- for example, Windows has no equivalent to a POSIX fork() call. The code you're compiling under MinGW has no MSYS or Cygwin dependencies, but the compiler and tools themselves (gcc, bash, the linker, etc.) do.

replies(2): >>11391545 #>>11391576 #
vram22 ◴[30 Mar 16 18:09 UTC] No.11391576[source]▶
>MSYS and MSYS2 actually are Cygwin

Not the person you're replying to, but interesting ...

>tools like GCC or Bash expect the system to support POSIX APIs and have POSIX semantics-- for example, Windows has no equivalent to a POSIX fork() call.

So do Cygwin and/or MSYS emulate the fork() call on Windows? and if so, do you have any idea how that is done? Just interested, since I have a Unix background - not at deep OS level, but at app level and also at the level of the interface between apps and the OS (using system calls, etc.).

replies(2): >>11391601 #>>11391797 #
bitcrazed ◴[30 Mar 16 18:37 UTC] No.11391797[source]▶
> So do Cygwin and/or MSYS emulate the fork()

Yes. That's one thing we spent considerable engineering effort on in this first version of the Windows Subsystem for Linux: We implement fork in the Windows kernel, along with the other POSIX and Linux syscalls.

This allows us to build a very efficient fork() and expose it to the GNU/Ubuntu user-mode apps via the fork(syscall).

We'll be publishing more details on this very soon.

replies(3): >>11392108 #>>11392461 #>>11396399 #
vram22 ◴[30 Mar 16 19:16 UTC] No.11392108[source]▶
Interesting! thanks. The original Unix fork() was found to be somewhat expensive in resources (a little surprising since it was the only way to create a child process), later there was vfork() (copy-on-write) (maybe innovated by BSD), and I read Linux's clone() does even better, though not looked into it in detail.
replies(2): >>11392775 #>>11398348 #
1. JoshTriplett ◴[31 Mar 16 16:23 UTC] No.11398348[source]▶
In Linux, fork(), vfork(), and clone() all use the same underlying machinery, with just a few different flags. clone() is the most general, with flags for what to share; those flags in particular include all the Linux namespaces that serve as the basis for containers. fork() just uses clone() with a hardcoded set of flags, and vfork() does the same as fork() except that it doesn't schedule the parent process until the child calls exec.
replies(1): >>11399937 #
2. vram22 ◴[31 Mar 16 19:36 UTC] No.11399937[source]▶
Interesting, will have to check that out.