←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 #
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 #
sbarre ◴[] No.11392208[source]
Your first point describes me exactly (and many other developers I know). I grew up a Windows user, and switched to OS X because of the unix-like command line environment that more closely matched the servers I was working with in my job environments.

I would most likely switch back to Windows as my primary/only machine (because I also like to play video games sometimes) if I had the same kind of unix-like command line environment that I get in OS X.

Right now I basically need 2 computers at home to meet all my needs, but this would allow me to reduce it to one, so I could get a much better one (instead of the 2 mid-range ones I have now).

replies(2): >>11392368 #>>11394465 #
13of40 ◴[] No.11392368[source]
> I grew up a Windows user, and switched to OS X because of the unix-like command line environment that more closely matched the servers I was working with in my job environments.

Out of curiosity, why would you not just go with a Linux desktop for that?

replies(12): >>11392577 #>>11392578 #>>11392619 #>>11392621 #>>11392642 #>>11392651 #>>11392661 #>>11392930 #>>11394153 #>>11394378 #>>11394527 #>>11396211 #
fauigerzigerk ◴[] No.11392930[source]
Same history here. I did actually use Linux for quite a while but ultimately gave up because Linux just isn't good at the one job only an operating system can do, which is to make the hardware available in a reliable and efficient manner.

I just got tired of fixing sound issues, trying to make a scanner work or investigating CPU states to fix heat and battery draining issues on yet another laptop. Ultimately, I think, all of this is a result of the unresolved issue of who should write and test device drivers.

It doesn't help that I disagree profoundly with the prevailing package management philosophy of Linux distributions, but that is a comparably superficial problem that can be worked around.

replies(2): >>11393645 #>>11394602 #
viraptor ◴[] No.11394602[source]
That's anecdata. Of course it can work the other way too. I've got a printer/scanner which "just works" with Linux. On Windows however they need crazy, proprietary driver/application which always lives in the traybar and tries hard to take over native windows settings.
replies(1): >>11395832 #
1. fauigerzigerk ◴[] No.11395832[source]
>That's anecdata

Sure, that's what this whole thread is about. But I'm afraid that there is causality involved that we know about without collecting any sample data at all.

Developers of Linux device drivers for consumer devices quite often do not have access to all the hardware and information they need. And hardware makers quite often do not make high quality Linux device drivers for their consumer devices. For most consumer laptops, the vendor will not do integration testing to make sure everything works well together on Linux.

I don't think the right response to that is to deny that the average laptop or peripheral will work better with Windows. The right response is to make it clear that you have to make very deliberate hardware choices if you plan to use Linux and accept that much of the hardware you can use is always going to be slightly dated. And that is in fact what many Linux advocates are saying.

Choosing a Mac also restricts your hardware choices quite dramatically after all, so if a broad selection of hardware is your goal, Windows is the only game in town.