On Apr 13, 2016, at 6:56 AM, KARL BOTTS <kdbo...@usa.net> wrote: > > why didn't MS just arrange to support Cygwin more > directly, e.g., make a "blessed" distribution mechanism for Cygwin available > to their users?
Many reasons. The first must be licensing. Realize that UfW is a kernel-level feature, which means adopting Cygwin into Windows would taint the kernel with the GPL. That’s a complete non-starter for Microsoft. Second, this new mechanism uses the NT subsystems feature, which means the WSL (Windows Subsystem for Linux) API isn’t available to programs built against the regular Windows API, since that’s a different subsystem. Any given program can run against only one NT subsystem. That means Cygwin can’t “just” call the new fork() WSL syscall. Third, given a choice between the Cygwin package repo and the Ubuntu package repo, well, no contest, yes? That’s also why Ubuntu and not, say, Fedora or Arch; Microsoft chose the biggest single package repo available. > I do not think they have really considered the integration issues that Cygwin > has mostly solved. Since when has Microsoft ever been immune from NIH syndrome? > small things like cygpath A cygpath like facility is neither useful nor needed in UfW. The programs run in their own Ubuntu world, and can’t talk to native Windows .exes directly. The only access to Windows paths is through /mnt/c and such. Within the UfW world, there are only POSIX paths. > Remember, they have tried basically the same thing at least twice before: the > "POSIX Subsystem" of WinNT Yes, and this is another such subsystem, with the same powers and limitations. The big difference this time is that it isn’t a gimped bare-bones POSIX subsystem, it’s a gimped Ubuntu subsystem. Ubuntu with severe limitations is still highly useful; witness Raspian. > And PowerShell is sort of another try Oh, I don’t know about that. PowerShell is the result of looking at all the things that suck about cmd.exe and POSIX shells and trying to solve them all at once while disregarding what made them useful. PowerShell ended up semi-useless for the same reason that a Perl or Python shell for Linux would be semi-useless: too much typing for day-to-day interactive use, no discoverability, and cryptic but Googleable one-line error messages replaced with programmer-geek stack traces. Someone told the PowerShell developers that the great thing about the POSIX shells is that they let you write programs, not just execute programs, so they said, “well, what sort of programming tools do we have…I know, .NET!” and wrapped that world in a shell. But that’s no more use as an interactive command shell than irb would be on Linux. Then you get the Stockholm Syndrome victims claiming that streams of objects are inherently superior to streams of bytes because they don’t require parsing. Never mind problems of discovery; no one ever created a POSIX shell IDE — who ever needed one? — but PowerShell without the IDE is nearly useless for anything complicated, because its APIs are hidden behind object interfaces, discoverable only through the reflection APIs and MSDN. But to drag all of this back on topic, UfW is Microsoft saying, “Yes, we know we screwed up. Please accept this full apology.” A whole lot of people are going to accept that gratefully. You can disregard a whole lot of the limitations with regard to Cygwin, too. Free and included in the box beats better-but-third-party in almost every case. Witness the long years of IE in the 60-90% market share range. It took national government level lawsuits and years of competition to break its hold on the market. > do you all know > that they started from the old ksh sources, somehow? I can believe early prototypes did, but I doubt any of that remains in the current implementation. It certainly doesn’t show in actual use of the shell. If any of that code remained, you would imagine some kind of user-visible residue, like the availability of heredocs. > trying to pipe PS output into a bash script, or vice versa, is a > nightmare. I have given up. That happens because PowerShell cmdlets are context-sensitive, and thus may give different output when run interactively vs when run in a pipeline. Every cmdlet emits a list of objects, not a list of text, so when run interactively, PowerShell calls the objects’ ToString() method to get the displayed output. When you then try to grep (or sls) that, it often fails because the object representation doesn’t have the target string. One solution is to put “| out-string -stream” between the source and the sink, to force everything to its text representation. This is the discoverability problem I brought up above. On a POSIX system, you run a command and see what you have to work with, and can directly devise a solution given the example above your command line in the scroll buffer. Under PowerShell, you run a command line, get a given output, but then still have no obvious solution because the command’s representation may materially change in a pipeline, so now you have to go chasing through the MSDN docs or reflection APIs to work out how to crawl its list-of-objects representation. > At the end of the day, mass Windows users just don't get the whole idea of a > shell as an integrator of software tools. Your statement is a tautology: once someone learns a POSIX shell, whether it’s under Linux, OS X, Cygwin, or Ubuntu for Windows, they are not longer “mass Windows users”. In other words, it is only a correct statement because “mass Windows users” haven’t seen a shell done properly. As soon as they do see it, they no longer fall into that category. > suspect that will lead MS to screw up their Unix environment, to make it more > friendly to their primary user base. Which will make it useless to me. I think you haven’t been paying attention to the revolution in progress at Microsoft under Nadella. The primary target for this tool set are all the mainstream Windows developers looking at cloud and mobile deployment. Microsoft is finally getting that Windows-in-the-Cloud is a non-starter for most applications and that Windows Mobile is a flop, so they’re embracing these other platforms, starting with Azure years ago, through open-sourced .NET tooling, then .NET Core, the purchase of Xamarin, and now UfW. Basically, Microsoft wants you to use their tooling, no matter where you deploy. That keeps them relevant, so that even if you don’t deploy primarily on Windows, you will still develop there, so that Windows apps developed that way won’t look like third-party platform ports like you get on OS X and Linux. A concrete example: All those soul-patch web developers choose to carry Mac laptops not just because they’re the hipster choice, but because Node runs much better under OS X than Windows. That proposition wholly changes in this UfW world: run node.js in the Ubuntu box and connect to it over the OS’s shared network stack from the Windows GUI browser of your choice. Microsoft must be getting mighty sick of seeing rows and rows of Apple logos on laptops in the audiences at the Build conference every year. UfW is one way they’re trying to change that. > I'll give it a year or two to settle I expect it to be quite usable in a matter of months. Microsoft can move awfully fast once the fires get lit. > I just hope it does not interfere too much with my Cygwin setup UfW will be completely independent of Cygwin. More’s the pity, because it means you’ll be incentivized to choose one or the other, likely to Cygwin’s net detriment. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
