←back to thread

Ubuntu on Windows

(blog.dustinkirkland.com)
2049 points bpierre | 9 comments | | HN request time: 0.001s | source | bottom
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 #
icefox ◴[] No.11391895[source]
Some long term thoughts:

1) Linux has won the server (web) market. Developers would like to use a Unix box to work on their server code so they typically move to OS X. This could prevent that switch because they can still use Windows to developer their Linux server software.

2) Many projects start out as Linux and stay Linux and are only ported after much time and effort to Windows. Enterprises when faced with a tool that they want to use will also look to switch off Windows. Now rather than the cost of switching they only have to pay to upgrade their windows boxes to use the tool.

3) There is now a major incentive for developers to only build Linux binaries because it will work more places. This might cause a faster drain of developers as they eventually remove all windows specific code and can more easily migrate elsewhere. This feels eerily similar to the OS2 story and no doubt in the next week I expect to see more than a few articles discussing this very thing.

4) It will be much easier for Microsoft to bring much loved Linux tools to Windows so you can expect to see a more rapid increase of tools announced that now work for Windows.

5) Games: What about the graphical layer? Can I write the majority of my game as a Linux binary and only have the rendering bit left over to separately implement for Linux/Windows? Will this spur an increase of cross platform games?

replies(5): >>11392137 #>>11392161 #>>11392208 #>>11392257 #>>11397240 #
TillE ◴[] No.11392257[source]
On a practical level, this doesn't change anything for games. Anyone writing games for Linux is already using cross-platform tech like SDL or OpenGL or Allegro, or one of the many increasingly popular high-level engines.

Well, I guess it'll be easier to port roguelikes which use ncurses.

replies(2): >>11392322 #>>11392672 #
1. chris_wot ◴[] No.11392322[source]
I'm really hoping this allows me to compile LibreOffice on Windows. Perhaps if I worked out how to incorporate the WINE libraries it might make my life easier...
replies(1): >>11392409 #
2. simoncion ◴[] No.11392409[source]
> I'm really hoping this allows me to compile LibreOffice on Windows.

Is this not helpful?

https://wiki.documentfoundation.org/Development/BuildingOnWi...

LibreOffice has official Windows builds, so I would expect that they can already build the software on Windows.

replies(1): >>11392954 #
3. chris_wot ◴[] No.11392954[source]
It means I need to install Visual Studio. Right now I'm only developing on Mac OS X and Linux. On top of this, every time Microsoft updates Visual Studio, things like firebird tend to break :(

I'd rather use a toolchain I know better. In fact, I'd love to use clang on Windows.

replies(2): >>11393401 #>>11393687 #
4. voltagex_ ◴[] No.11393401{3}[source]
The latest Visual Studios support clang.
5. simoncion ◴[] No.11393687{3}[source]
> It means I need to install Visual Studio.

I mean, sure, but (unless things have changed dramatically in the many years since I was a Windows dev) you don't have to do anything more than install VS. The compilers and nmake can be used without opening the GUI. IIRC, you can feed a VS project file (or -I'm pretty sure- a solution file) to nmake and get the same result you'd get from loading the GUI and pressing build.

replies(2): >>11393725 #>>11394736 #
6. chris_wot ◴[] No.11393725{4}[source]
Definitely time for me to get off my backside and install Visual Studio then...
7. yuubi ◴[] No.11394736{4}[source]
Confirming you can feed a .sln file to msbuild (I did it the other day), no idea about whether nmake accepts them. Source: https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin3... .
replies(1): >>11394851 #
8. simoncion ◴[] No.11394851{5}[source]
Ah, shit. I couldn't remember if the damn thing was called msbuild or nmake. [0] I guess one should replace all instances of nmake in my comment with msbuild.

[0] I do know that they are both parts of the VS build tooling. ;)

replies(1): >>11395056 #
9. yuubi ◴[] No.11395056{6}[source]
I think nmake is or was a normalish make.