←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 #
drinchev ◴[] No.11391381[source]
Just a remark. npm's team fixed long paths in v3.0, so now you have "flat tree".
replies(1): >>11391654 #
1. mmebane ◴[] No.11391654[source]
The "maximally flat" package structure in npm 3 solves the problem in most common cases, so I suppose "much more useful" was an exaggeration - if you keep your code in a relatively short base directory such as C:\src\nodeprojects\left-pad-ng\, you'll probably be fine.

Depending on what version ranges dependencies are locked to, you could still end up with a pathological situation which breaks the path length limit, but I've only had that happen once since switching to npm 3, and it was easy to resolve.