Ubuntu on Windows

(blog.dustinkirkland.com)

Show context

captainmuon ◴[30 Mar 16 17:35 UTC] No.11391214[source]▶

A few random thoughts:

- Wow, hell is really freezing over!

- The hardest part of running bash and other posix things under windows is filesystem access. Windows uses drive letters and backslashes, unix has a root filesystem with forward slashes. It seems they are taking the same route as cygwin by "mounting" windows drives in /mnt/c (or /cygdrive/c).

- If you just wanted bash and some posix tools, the harder but nicer way would be to patch them to understand windows paths. It is not clear to me that it is even possible, for example many tools assume a path that does not start with a slash is a relative path - while "C:\" is absolute. You would also want to make more windows apps understand forward slashes like "C:/Windows". To make things even more complicated, there are NT native paths "\Device\HarddiskVolume4\Users\Bill", UNC paths "\\Server\share", and the crazy syntax "\\?\C:\MyReallyLongPath\File.txt".

- I am really surprised this works in an appx container. From my little dabbling with modern apps in Visual Studio, I've found that they are incredibly sandboxed - no filesystem access unless you go through a file picker, no network connections to localhost (!?), no control of top-level windows, no loading of external DLLs. You can get around most restrictions for sideloaded apps, but not for windows store apps. That they can now package such a complex application as a modern app (with maybe only the linux subsystem DLLs delivered externally) means that they are slowly moving the modern/universal apps and traditional Win32 apps together with regards to their powers.

- Running a Linux kernel in windows, and then ELF executables on top (without virtualization) is nothing new, see CoLinux or andLinux. If I understand correctly, this new work uses a new Linux NT subsystem. It remains to be seen if this is better (more performant) or worse (if the Linux kernel is just another process, and it crashes, it doesn't take down the system).

- If they actually wrote a NT subsystem for Linux, this opens a whole can of GPL licensing worms, as you'll need to include internal NT headers. However, they say it is closed source, so I wonder how they did it.

- This really stands and falls with how well it is integrated in the rest of the system. I want to install tools in "Ubuntu" via apt and use them from cmd.exe, and vice versa. And long term, a X11/Wayland bridge would be nice too.

replies(7): >>11391240 #>>11391243 #>>11391895 #>>11391990 #>>11392163 #>>11392791 #>>11395063 #

barrkel ◴[30 Mar 16 17:38 UTC] No.11391240[source]▶

>>11391214 #

I expect they implemented a subsystem for Linux at the syscall level - i.e. they implemented the Linux kernel's interface at the ABI level. No headers would need to intermingle with open source; compile on Linux, run on Windows.

replies(4): >>11391417 #>>11392330 #>>11392474 #>>11392769 #

whatever_dude ◴[30 Mar 16 17:53 UTC] No.11391417[source]▶

>>11391240 #

I've read comments where people wrote that NT always had some kind of POSIX subsystem, and it has probably just now been completed and expanded.

Can't find any substantial writings on this, but it seems likely.

replies(4): >>11391513 #>>11391676 #>>11392248 #>>11392369 #

1. barrkel ◴[30 Mar 16 18:02 UTC] No.11391513[source]▶

>>11391417 #

Not only did NT have a POSIX subsystem, but once upon a time I used it (when it was packaged as SFU, Services for Unix). It wasn't a pleasant experience.

This will have been quite a bit more work than just a POSIX layer, IMO; POSIX defines a bunch of low-level functions that lie just under the C runtime library, but Linux defines a bunch more that expect a certain view of the world - things like clone(2), which lets you selectively choose what the forked process gets to inherit. POSIX only specifies fork(2). Linux implements fork(2) in terms of clone(2). And POSIX defines the API at the level of C; this will have had to implement the Linux ABI, where it differs from Win64. A minor detail of a bunch of assembly stubs, but work nonetheless.

replies(3): >>11392546 #>>11394779 #>>11418098 #

2. LukeShu ◴[30 Mar 16 20:09 UTC] No.11392546[source]▶

>>11391513 (TP) #

To nitpick: On Linux, glibc implements fork(3) in terms of clone(2). Linux still has an independent fork(2), but nothing uses it.

3. alwaysdownvoted ◴[31 Mar 16 03:21 UTC] No.11394779[source]▶

>>11391513 (TP) #

I still use SUA every day when I'm forced to use Windows. (I also run Linux binaries on BSD.)

SUA is based on an old version of BSD, not GNU. tcsh, csh and sh. The compiler works. There is an old version of lex. For some of the userland, Windows binaries are provided, such as vi. It's better than nothing.

Why did MS remove SUA from Windows 10? What harm would it do to remain an optional add-in as it was in Windows 7?

Why do users have to upgrade to Windows 10 to use Linux binaries? Seems like Microsoft will do _anything_ to get users to upgrade. What are the privacy implications of Windows 10? Microsoft is very untrustworthy.

Will users be able to run their own Linux binaries on Windows?

Windows has never been a "pleasant experience". It's the unpleasantness of it that makes the alternative, UNIX, so appealing.

replies(2): >>11396094 #>>11418162 #

4. ◴[31 Mar 16 10:20 UTC] No.11396094[source]▶

>>11394779 #

5. JdeBP ◴[03 Apr 16 22:32 UTC] No.11418098[source]▶

>>11391513 (TP) #

> It wasn't a pleasant experience.

In my experience the differing perception of pleasure, certainly with the Interix-derived Windows NT POSIX subsystem rather than the original one, is usually a result of the toolset being BSD rather than GNU. I don't have much trouble with the BSD toolset, myself, especially when switching between Windows and an actual BSD. (-:

In addition to the fact that a number of the "Does this new subsystem ...?" questions are answerable as "No; but the old POSIX subsystem did." (https://news.ycombinator.com/item?id=11416392) the POSIX subsystem has some stuff that we're simply not going to get with a Linux subsystem that has vanilla Linux binaries including libraries right down to the system call level. There are things that only come by adjusting libraries and binaries, because they are above the raw system call level. The POSIX subsystem integrates the user account database access library routines with the Windows SAM, for example. So "ls -l" shows the actual Windows usernames. The POSIX subsystem also comes with a "service" command that understands and can work with the SCM, for another example.

I'd like to see the POSIX subsystem reintroduced. It's a major reason not to use Windows 10.

6. JdeBP ◴[03 Apr 16 22:44 UTC] No.11418162[source]▶

>>11394779 #

> The compiler works.

... but is too outdated to be capable of bootstrapping clang. There's very probably a long chain of bootstraps that would achieve it, but there's not a direct route.

> Will users be able to run their own Linux binaries on Windows?

The answer to that is easily determined from the demo video that Microsoft published. In it, Russ Alexander compiles a program with (Ubuntu binary) GCC and and runs it.

Its implicit int in the declaration of main() was jarring. (-:

↑