←back to thread

Ubuntu on Windows

(blog.dustinkirkland.com)
2049 points bpierre | 1 comments | | HN request time: 0s | source
Show context
captainmuon ◴[] 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 #
mmebane ◴[] No.11391243[source]
> It seems they are taking the same route as cygwin by "mounting" windows drives in /mnt/c (or /cygdrive/c).

I wonder if this Unix filesystem layer will be able to break the Windows legacy path length limit. If so, the Linux version of Node.js will suddenly become much more useful than the Windows version.

> It remains to be seen if this is better (more performant) or worse

Sounds like performance, at least, will be better. TFA says "it's totally shit hot! The sysbench utility is showing nearly equivalent cpu, memory, and io performance." I'll reserve judgment until I see the fork() benchmarks. :)

replies(3): >>11391381 #>>11391508 #>>11392092 #
bpye ◴[] No.11391508[source]
http://stackoverflow.com/a/67293/3965517 indicates that NT does support fork properly, just not exposed to usermode normally.
replies(1): >>11391876 #
1. pcwalton ◴[] No.11391876[source]
fork() is exposed to user mode, but it's an undocumented private API. Pass the handle of the parent process as the 4th parameter and TRUE as the 5th parameter to NtCreateProcess: http://undocumented.ntinternals.net/index.html?page=UserMode...

The problem is that the Win32 user mode system will fight you every step of the way: CSRSS will not understand what you just did, for example. It's not generally worth it.