This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: native Linux userland in Windows 10

On Apr 13, 2016, at 6:56 AM, KARL BOTTS <> 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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]