Rethink your strategy on how the linux/bash integration should work
I'm pleased to see Microsoft making the effort to bring bash to Windows, unfortunately I feel like the approach taken is mostly cosmetic and segregates POSIX applications rather than embracing them. Some comments on the "Run Bash on Ubuntu on Windows" rightly highlight that this is slightly better Ubuntu VM with samba mounts.
Microsoft should *want* to create a new architecture/target/platform that builds to Win32 executables and maintain an apt repository for it. Much the same as how debian builds for BSD as well as Linux: We've all heard GNU/Linux, so why hasn't this effort just been to facilitate GNU/Win32?
I've made suggestions via Windows feedback in the past that sound similar to what's being done with bash, but I highly recommend Microsoft and anyone reading check out MSYS2: https://msys2.github.io/
This is by far the best integration of POSIX applications with Win32 I've seen to date. To the point that I've been able to open tickets on FOSS projects explaining that flatly detecting the platform as Win32 and bailing on features isn't always necessary. Some people are actually running bash on Win32 already *today* and because of that fact, this functionality might be obsolete before it's even released.
Rather than duplicating efforts and further dividing the community by producing yet another way to run POSIX applications on Windows, Microsoft should be trying to unify it for reasons very similar to what other people have mentioned:
- Why should I install a linux-java and a Windows-java and have them never able to speak?
- Why should I have an emulated FHS structure?
- Why do my POSIX applications have to be sheltered from the true underlying permissions system?
I understand that you've scoped this effort as "for developers only", which seems to translate to "a command line jail". I don't necessarily agree with that goal though and feel like I should be able to run a binary that uses GTK - but that the GTK library it ends up talking to happens to be targeting the Windows desktop.
I understand that there are differences between *nix and Windows, but that simply defines the problem you should actually be addressing. It's certainly been visited in the past with the various incarnations of SFU.
Instead of enshrining the differences - rework the efforts being done here into a true platform that the community can recognize as the first-class, definitive POSIX-on-Windows.
Anonymous
shared this idea
You make some fair observations, but also miss the big point here:
There’s no way we can convince the entire *NIX community to re-build their tools to target Win32, nor to publish their Win32 apps to apt-get which, itself, depends on many *NIX features and behaviors that are incompatible with Windows.
As has been pointed out below, the original POSIX and later Interix/SFU subsystems did what you suggested, but got practically zero traction in the market.
WSL is built to be distro-agnostic (we’ll get to other distro support in the future), and is able to natively run unmodified ELF64 binaries. This enables pre-built binaries to be distributed (vs. source), and is perhaps the key reason for Linux’s rapidly growing popularity with developers.
Also, welding together two OS philosophies into one, without breaking one or the other is practically impossible – that’s why WSL tries to maintain as high a degree of compatibility with Linux’ ABI as possible – users just want stuff to work.
Bear with is on this journey – we’ve only just got started and have big plans ahead ;)
4 comments
-
Meteorhead
commented
Perhaps they need be separated, because they differ too much. *nix has a root user, able to do everything. Windows has Administrator privileges (not a standalone user), but it is not capable of doing everything. Some actions can only be taken by the System user. There is really no good mapping to POSIX permissions.
Aside from that, I have had very bad experiences with the FOSS when it comes to interoperability. Even when a project uses plain old C++, convincing the project to use CMake instead of autoconf to detect configuration AND get the build going... it's an uphill battle.
I would love to live in the world you imagine, but I don't see it becoming a reality for a myriad of reasons.
-
Antoine Leca
commented
Mmmm... The former POSIX subsystem (Interix, SFU, SUA) did more or less what you are proposing (it was not Win32 executables originally, but with Interix-added support they were inter-operatable) and it did not perform very well. I believe the new approach, with a strong bias toward existing, tested, up-to-date etc. packages available out-of-the-box, is more likely to have success.
-
Negi commented
I think one of the reasons why more integration could be a problem is that if Microsoft effectively sandboxes the opensource software and simply runs it with the NT-Kernel with the Linux subsystem layer serving as a drop-in replacement for the Linux kernel, Microsoft has no risk of legal liability, forcing them to expose some of the unpublished interfaces of the NT Kernel.
Anyway, it doesn't really matter for development, because you could, essentially with no latency and pretty low overhead, do IPC through TCP/IP routing of data together with some app that can translate paths in the win32 side to paths in the ubuntu side.
You could always do 90% this by running a virtualized copy of linux and loading any of the apps you wanted in Windows though ssh terminal sessions. What is nice now (or in the near-future) is that you can have the Windows kernel give the Linux side an environment that is actually based on the real machine. You could populate /proc/registry with the windows registry and whatever.
It's better if Microsoft does what they can do without violating the GPL, because if they do violate the GPL and have a lawsuit or whatever, the whole project will just be shut down by the management.
-
o9000
commented
> - Why should I have an emulated FHS structure?
How else would you port scripts from Linux to Windows? They would crash since there is no "/", "/home", "/etc", "/proc" and so on.