RE: native Linux userland in Windows 10

RE: native Linux userland in Windows 10

[KARL BOTTS]

What baffles me is, why didn't MS just arrange to support Cygwin more
directly, e.g., make a "blessed" distribution mechanism for Cygwin available
to their users?  Surely this could have been worked out: they have some sort
of "partnership" with RedHat, they claim.

I put a lengthy comment to that effect in the forum associated with that
video, after a colleague who was at the "Build Conference" in SF emailed it to
me last week.  (There may be more than one video.)

I do not think they have really considered the integration issues that Cygwin
has mostly solved.  Not just permissions, but small things like cygpath and
such utilities.  No doubt they can, but will they stick to it long enough to
make everything work?  I have my doubts.

Remember, they have tried basically the same thing at least twice before: the
"POSIX Subsystem" of WinNT, and the "Unix Tools for Windows".  Both failed and
have been abandoned.  And PowerShell is sort of another try: do you all know
that they started from the old ksh sources, somehow?  But they totally screwed
up PS, from my point of view, by making it deal primarily with binary streams
of proprietary data instead of text.  That may make it better for a former
CMD.EXE user, but it does not integrate at all with anything else.  For
instance, trying to pipe PS output into a bash script, or vice versa, is a
nightmare.  I have given up.

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.  They think it is supposed to make
pretty pictures in a console emulator, as a poor substitute for a GUI.  I
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 could be wrong.  I'll give it a year or two to settle, and then give it a
try.  I just hope it does not interfere too much with my Cygwin setup, which I
expect to keep for the foreseeable future.


---
Karl Botts, kdbotts@usa.net


--
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

Re: native Linux userland in Windows 10

[John Cowan]

KARL BOTTS scripsit:

> Remember, they have tried basically the same thing at least twice
> before: the "POSIX Subsystem" of WinNT, and the "Unix Tools for Windows".

Actually, Microsoft hasn't.  The Posix subsystem never did anything
useful and was just a cynical hack to satisfy government checklists.
Must support Posix -- check.  But most limits were set as low as they
could go.  OpenNT/Interix/WSU was a third-party product, and was an
entirely separate implementation of Posix, not quite matching any existing
OS.  I ported a large proprietary Linux C++ program to it as a proof
of concept, and there were a lot of issues but it did eventually work.
The intention here is to match the Linux kernel, at least up to a point
(and nobody knows what that point is).

> I could be wrong.  I'll give it a year or two to settle, and then give it a
> try.  I just hope it does not interfere too much with my Cygwin setup, which I
> expect to keep for the foreseeable future.

It definitely doesn't affect Cygwin in any way.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
"Your honour puts yourself to much trouble correcting my English and
doubtless the final letter will be much better literature; but it will
go from me Mukherji to him Bannerji, and he Bannerji will understand it a
great deal better as I Mukherji write it than as your honour corrects it."
        --19th-century Indian civil servant to his British superior

--
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

Re: native Linux userland in Windows 10

[Warren Young]

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

Re: native Linux userland in Windows 10

[Andrew Schulman]

> That means Cygwin can’t “just” call the new fork() WSL syscall.

Bummer.


--
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

Re: native Linux userland in Windows 10

[Andrey Repin]

Greetings, Warren Young!

>> 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.

Which means, I can't call diff between files on my file manager's two panels?

>> 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.

Raspian is an operating system.
This… this, I don't know how to call it, but it's a complete joke.

> 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.

At the same time, you could run any given VM and get much better options and
choices.

> 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 wouldn't be so hasty. If there's no interfacing between subsystems, it is as
useful as running a VM. Read: useless crap, when it is going to usability.

>> 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.

Since it will be independent of Windows as well as Cygwin, the choice is a
nobrainer.


-- 
With best regards,
Andrey Repin
Thursday, April 14, 2016 21:54:53

Sorry for my terrible english...

Re: native Linux userland in Windows 10

[Eliot Moss]

On 4/14/2016 3:07 PM, Andrey Repin wrote:

It was mentioned that you can mount the Windows file system,
so I don't see why you can't work with both Linux and Windows
files from within the Ubuntu universe ...

Eliot Moss

--
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

Re: native Linux userland in Windows 10

[John Cowan]

Andrey Repin scripsit:

> Which means, I can't call diff between files on my file manager's two panels?

What on earth does that mean?

In any case, though it is hard to be sure (no /etc/fstabs file), I
think that /mnt/c is hardwired into lxss, not the result of a Linux-level
mount operation.

> At the same time, you could run any given VM and get much better options and
> choices.

Of course.  And you could have even more options and choices with a
separate Linux box.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
There are three kinds of people in the world:
those who can count, and those who can't.

--
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

Re: native Linux userland in Windows 10

[Andrey Repin]

Greetings, John Cowan!

> Andrey Repin scripsit:

>> Which means, I can't call diff between files on my file manager's two panels?

> What on earth does that mean?

Welcome, poor child of a big blue button. Let me introduce you into my world.
The world, where file managers help you manage files.

> In any case, though it is hard to be sure (no /etc/fstabs file), I
> think that /mnt/c is hardwired into lxss, not the result of a Linux-level
> mount operation.

Right now, I hit Alt+Shift+D, which invokes a short macro calling menu entry
view:<? diff -x "CVS" -x ".svn" -I "\$Id.*\$" -I "\$Rev.*\$" -I "\$Date.*\$" -I "\$Author.*\$" -I "\$URL.*\$" -I "^Orbiting .*$" !?$UnixDiff$Options ((-c, -b etc.)):?! --strip-trailing-cr -- "!#!\!.!" "!^!\!.!"
and get two files (or directories) on opposite panels diffed into an internal
viewer. Because Cygwin diff consume normal Windows paths without an issue.

>> At the same time, you could run any given VM and get much better options and
>> choices.

> Of course.  And you could have even more options and choices with a
> separate Linux box.

How is this relevant to the discussion?


-- 
With best regards,
Andrey Repin
Friday, April 15, 2016 01:30:47

Sorry for my terrible english...


--
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

Re: native Linux userland in Windows 10

[John Cowan]

Andrey Repin scripsit:

> Welcome, poor child of a big blue button. Let me introduce you into my world.
> The world, where file managers help you manage files.

"The Jews have no dealings with the Samaritans."  I live in a word of
command lines almost exclusively, unless I am running a Web browser.
Consequently, the underlying system can be Linux, BSD, OS X, Cygwin,
or none of the above.  When I want to see a diff, I type
"diff file1 file2 | less".

> Right now, I hit Alt+Shift+D, which invokes a short macro calling menu entry
> view:<? diff -x "CVS" -x ".svn" -I "\$Id.*\$" -I "\$Rev.*\$" -I "\$Date.*\$" -I "\$Author.*\$" -I "\$URL.*\$" -I "^Orbiting .*$" !?$UnixDiff$Options ((-c, -b etc.)):?! --strip-trailing-cr -- "!#!\!.!" "!^!\!.!"
> and get two files (or directories) on opposite panels diffed into an internal
> viewer. 

Very efficient, I'm sure.  But to each their own.

> Because Cygwin diff consume normal Windows paths without an issue.

No doubt.  But it also handles /cygdrive/c paths, the moral equivalent
of /mnt/c paths, and that's what I use.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
And they pack their lyrics till they're so damn dense
You could put 'em in your yard and you could use 'em for a fence.
      --Alan Chapman, "Everybody Wants to Be Sondheim"

--
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

Re: native Linux userland in Windows 10

[Andrey Repin]

Greetings, John Cowan!

>> Right now, I hit Alt+Shift+D, which invokes a short macro calling menu entry
>> view:<? diff -x "CVS" -x ".svn" -I "\$Id.*\$" -I "\$Rev.*\$" -I "\$Date.*\$" -I "\$Author.*\$" -I "\$URL.*\$" -I "^Orbiting .*$" !?$UnixDiff$Options ((-c, -b etc.)):?! --strip-trailing-cr -- "!#!\!.!" "!^!\!.!"
>> and get two files (or directories) on opposite panels diffed into an internal
>> viewer. 

> Very efficient, I'm sure.  But to each their own.

Of course, it is efficient.
More efficient, than starting a shell each time I need to diff a file.
Or 2-3 shells, if you call a wrapper. Which is least efficient, considering
retarded CMD quoting rules.

>> Because Cygwin diff consume normal Windows paths without an issue.

> No doubt.  But it also handles /cygdrive/c paths, the moral equivalent
> of /mnt/c paths, and that's what I use.

Moral is a relative category.


-- 
With best regards,
Andrey Repin
Friday, April 15, 2016 12:50:52

Sorry for my terrible english...


--
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

Re: native Linux userland in Windows 10

[John Cowan]

Andrey Repin scripsit:

> Of course, it is efficient.
> More efficient, than starting a shell each time I need to diff a file.
> Or 2-3 shells, if you call a wrapper. Which is least efficient, considering
> retarded CMD quoting rules.

I always have 2-3 shells running, more if I am editing a lot of files.
But you live in a GUI world and I live in a CLI world.  This very email,
for example, like almost all my personal emails, is being written from
inside mutt using 'ex'.

And no, cmd does not count as a shell.

> Moral is a relative category.

If you don't know what "moral equivalent" means, either say so or look it up.

*plonk*

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
Nobody expects the RESTifarian Inquisition!  Our chief weapon is
surprise ... surprise and tedium  ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts....  Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding....

--
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

Re: native Linux userland in Windows 10

[Andrey Repin]

Greetings, John Cowan!

> Andrey Repin scripsit:

>> Of course, it is efficient.
>> More efficient, than starting a shell each time I need to diff a file.
>> Or 2-3 shells, if you call a wrapper. Which is least efficient, considering
>> retarded CMD quoting rules.

> I always have 2-3 shells running,

Having shells running, and having 2-3 shells start between a request and the
result is not quite the same thing, don't you think?

> more if I am editing a lot of files.

Having shells running for file editing? Sorry, what year you are living in?

> But you live in a GUI world and I live in a CLI world.

WHAT?

> This very email, for example, like almost all my personal emails, is being
> written from inside mutt using 'ex'.

That's your choice. Email client and browser is about all GUI apps I use
daily. Oh, wait. A download client is GUI too.
The rest is console. (Google "Far manager" one day. That's my #1, #2 and #3
tool for any given task. Except those two mentioned above.)

> And no, cmd does not count as a shell.

And yes, it do counts as a shell. By definition.

>> Moral is a relative category.

> If you don't know what "moral equivalent" means, either say so or look it up.

I know. Doesn't change my reply even a single bit.
Morale is a relative category. If YOUR understanding of "morale" includes a
given set of characteristics, this doesn't mean that everyone's definition of
"morale" includes the same set of characteristics.
What YOU considering "moral equivalent" may not be the case for someone else.


-- 
With best regards,
Andrey Repin
Monday, April 18, 2016 00:02:42

Sorry for my terrible english...


--
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

Don't descend into a flame war. was: Re: native Linux userland in Windows 10

[Herbert Stocker]

On 17.04.2016 23:27, Andrey Repin wrote:
> Greetings, John Cowan!
>
>> Andrey Repin scripsit:
>
>>> Of course, it is efficient.
>>> More efficient, than starting a shell each time I need to diff a file.
>>> Or 2-3 shells, if you call a wrapper. Which is least efficient, considering
>>> retarded CMD quoting rules.
>
>> I always have 2-3 shells running,
>
> Having shells running, and having 2-3 shells start between a request and the
> result is not quite the same thing, don't you think?
>
>> more if I am editing a lot of files.
>
> Having shells running for file editing? Sorry, what year you are living in?

Editors like vim and others do have advances that other editors don't
have. It's not a question of year, it's a question of preference.
And of whether one goes over a high learning curve (like you also did,
i know) or a shallow one and stays there. (like some i have to do with
daily).

>
>> But you live in a GUI world and I live in a CLI world.
 >
 > WHAT?

i for example live in both worlds. GUI for many things, and CLI for
those things where the GUI exposes its shortcomings. That's why i say
Cygwin makes that OS complete.


>
>> And no, cmd does not count as a shell.
>
> And yes, it do counts as a shell. By definition.
>
Using cmd to argue about cli is a mistake.

Much like looking at the big churches and judging about God.



Now that's off-topic by far..

Herbert




--
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

Re: Don't descend into a flame war. was: Re: native Linux userland in Windows 10

[cyg Simple]

On 4/18/2016 1:44 AM, Herbert Stocker wrote:
> On 17.04.2016 23:27, Andrey Repin wrote:
>> Greetings, John Cowan!
>>
>>> Andrey Repin scripsit:
>>
>>>> Of course, it is efficient.
>>>> More efficient, than starting a shell each time I need to diff a file.
>>>> Or 2-3 shells, if you call a wrapper. Which is least efficient,
>>>> considering
>>>> retarded CMD quoting rules.
>>
>>> I always have 2-3 shells running,
>>
>> Having shells running, and having 2-3 shells start between a request
>> and the
>> result is not quite the same thing, don't you think?
>>
>>> more if I am editing a lot of files.
>>
>> Having shells running for file editing? Sorry, what year you are
>> living in?
> 
> Editors like vim and others do have advances that other editors don't
> have. It's not a question of year, it's a question of preference.
> And of whether one goes over a high learning curve (like you also did,
> i know) or a shallow one and stays there. (like some i have to do with
> daily).

All editors are the color of blue, it's the shade of blue that you're
talking about. :D  When I first started working the only editor being
used by the ones that came before me was a line editor.  After I was
employed and started using a visual editor that incorporated a macro key
command everyone else came to me to learn that editor.  The point of an
editor is to do editing, some of those editors allow that to happen in a
faster fashion.  The faster you can produce the better you look to the
employer or client.

> 
>>
>>> But you live in a GUI world and I live in a CLI world.
>>
>> WHAT?
> 
> i for example live in both worlds. GUI for many things, and CLI for
> those things where the GUI exposes its shortcomings. That's why i say
> Cygwin makes that OS complete.
> 

A friend of mine says "Those who prefer a GUI have no CLUI."  You can
often be faster using CLUI (or CLI) than with a GUI.

> 
>>
>>> And no, cmd does not count as a shell.
>>
>> And yes, it do counts as a shell. By definition.
>>
> Using cmd to argue about cli is a mistake.

Again, cmd.exe is a shell that can be executed within the MinTTY
terminal.  Windows provides a default terminal for the cmd shell.  But
you're correct it is off topic.

-- 
cyg Simple

--
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

Re: native Linux userland in Windows 10

[Warren Young]

On Apr 14, 2016, at 1:07 PM, Andrey Repin wrote:
> 
>>> small things like cygpath
> 
>> A cygpath like facility is neither useful nor needed in UfW.
> 
> Which means, I can't call diff between files on my file manager's two panels?

Sure you can.  c:\tmp\foo.txt is seen as /mnt/c/tmp/foo.txt inside the UfW box.  That is, /mnt under UfW behaves much like /cygpath under Cygwin.

The only difference between UfW and Cygwin in this regard is that UfW doesn’t have any fallbacks for mixed-mode and DOS-style style paths.  Only POSIX paths work, which is the recommended way of working with Cygwin, too.  Microsoft is bypassing one of the most troublesome areas of day-to-day Cygwin use here by refusing to accept anything but POSIX paths.

(Open question: does UfW’s Bash shell accept UNC paths?)

>> Ubuntu with severe limitations
>> is still highly useful; witness Raspian.
> 
> Raspian is an operating system.
> This… this, I don't know how to call it, but it's a complete joke.

Hyperbolic much?

I’d say UfW checks off most of the defining characteristics of an OS: there’s a separate kernel and userland, it does scheduling, mediates IPC, keeps processes from stomping on each other…  About the only thing it doesn’t do is privilege separation, but if that’s a necessary qualification for a thing to be an OS, a Linux box booted into single-user mode isn’t an OS, either.

You could also think of it as a Linux personality on top of the NT microkernel, and it’s the microkernel that’s the OS.

>> 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.
> 
> At the same time, you could run any given VM and get much better options and
> choices.

You can make the same argument about Cygwin.  And yet, despite the free availability of top-quality VM technology, Cygwin continues to thrive.

UfW won’t fill 100% of the use cases of Cygwin from day 1, but for a lot of cases, the two will be interchangeable, so that the choice between them comes down to some practical consideration.  setup.exe vs Windows Store, Ubuntu package repo size vs Cygwin package repo size, native app speed vs the Cygwin DLL POSIX emulation speed hit, native Windows interaction vs siloed subsystems, etc.

>> I expect it to be quite usable in a matter of months.
> 
> I wouldn't be so hasty. If there's no interfacing between subsystems, it is as
> useful as running a VM. Read: useless crap, when it is going to usability.

Re: “useless”

“You keep using that word.  I do not think it means what you think it means.”

  — Inigo Montoya

>>> 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.
> 
> Since it will be independent of Windows as well as Cygwin, the choice is a
> nobrainer.

If that is your decision for yourself, that’s perfectly fine.  However, I predict that a whole lot of people will find uses for this technology, thereby making it “useful,” by definition.

--
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

Re: native Linux userland in Windows 10

[John Cowan]

Warren Young scripsit:

> (Open question: does UfW’s Bash shell accept UNC paths?)

No.  It treats a leading double slash as a single slash, despite the Posix
permission to do otherwise, and treats a non-leading double slash as an
error, despite the Posix requirement not to do that.  (I have reported
this bug to Feedback Hub.)  Thus, even though "cat ./dogs" works,
"cat .//dogs" returns ENOENT.

> I’d say UfW checks off most of the defining characteristics of an
> OS: there’s a separate kernel and userland, it does scheduling,
> mediates IPC, keeps processes from stomping on each other…  About
> the only thing it doesn’t do is privilege separation, but if that’s
> a necessary qualification for a thing to be an OS, a Linux box booted
> into single-user mode isn’t an OS, either.

Actually, it does do privilege separation independent of Windows.
I added cowan as a user with useradd -m, and I just do "su - cowan" by
hand as the first thing when the initial bash starts up.  All is well;
I get EPERM when I try to write into /bin.

> “You keep using that word.  I do not think it means what you think it means.”

/me grins.

> If that is your decision for yourself, that’s perfectly fine.
> However, I predict that a whole lot of people will find uses for this
> technology, thereby making it “useful,” by definition.

+1

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
If you have ever wondered if you are in hell, it has been said, then
you are on a well-traveled road of spiritual inquiry.  If you are
absolutely sure you are in hell, however, then you must be on the Cross
Bronx Expressway.  --Alan Feuer, New York Times, 2002-09-20

--
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

Re: native Linux userland in Windows 10

[Andrey Repin]

Greetings, Warren Young!

> On Apr 14, 2016, at 1:07 PM, Andrey Repin wrote:
>> 
>>>> small things like cygpath
>> 
>>> A cygpath like facility is neither useful nor needed in UfW.
>> 
>> Which means, I can't call diff between files on my file manager's two panels?

> Sure you can.  c:\tmp\foo.txt is seen as /mnt/c/tmp/foo.txt inside the UfW
> box.  That is, /mnt under UfW behaves much like /cygpath under Cygwin.

And how does that help?

> The only difference between UfW and Cygwin in this regard is that UfW
> doesn’t have any fallbacks for mixed-mode and DOS-style style paths.  Only
> POSIX paths work, which is the recommended way of working with Cygwin, too. 
> Microsoft is bypassing

More like dismissing.

> one of the most troublesome areas of day-to-day
> Cygwin use here by refusing to accept anything but POSIX paths.

The point of Cygwin for me was always an interoperability.
I can shift focus back and forth with minimal issues, if any.

>>> Ubuntu with severe limitations
>>> is still highly useful; witness Raspian.
>> 
>> Raspian is an operating system.
>> This… this, I don't know how to call it, but it's a complete joke.

> Hyperbolic much?

No, just a little.

> I’d say UfW checks off most of the defining characteristics of an OS:
> there’s a separate kernel and userland, it does scheduling, mediates IPC,
> keeps processes from stomping on each other…  About the only thing it
> doesn’t do is privilege separation, but if that’s a necessary qualification
> for a thing to be an OS, a Linux box booted into single-user mode isn’t an OS, either.

In other words, it's a virtual machine. About as useful as any other, and
there's way more useful and complete solutions already on the market.

>>> 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.
>> 
>> At the same time, you could run any given VM and get much better options and
>> choices.

> You can make the same argument about Cygwin.

No.

> And yet, despite the free
> availability of top-quality VM technology, Cygwin continues to thrive.

Because interoperability.

> UfW won’t fill 100% of the use cases of Cygwin from day 1, but for a lot of
> cases, the two will be interchangeable,

Name me a few. I can't imagine even "bash here" implemented in this... this.
Not to mention royally screwed permissions.

>>>> 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.
>> 
>> Since it will be independent of Windows as well as Cygwin, the choice is a
>> nobrainer.

> If that is your decision for yourself, that’s perfectly fine.  However, I
> predict that a whole lot of people will find uses for this technology,
> thereby making it “useful,” by definition.

Yes, of course. People always find uses for everything. Doesn't make it any
more useful.
And they will see no issues when moving from this crap to real *NIX system.
Always working as root? What could possible go wrong?


-- 
With best regards,
Andrey Repin
Friday, April 15, 2016 12:53:35

Sorry for my terrible english...

Re: native Linux userland in Windows 10

[Warren Young]

On Apr 15, 2016, at 4:04 AM, Andrey Repin <anrdaemon@yandex.ru> wrote:
> 
>> And yet, despite the free
>> availability of top-quality VM technology, Cygwin continues to thrive.
> 
> Because interoperability.

So the ability to run native Linux ELF binaries without recompilation on Windows is not “interoperability”?

>> UfW won’t fill 100% of the use cases of Cygwin from day 1, but for a lot of
>> cases, the two will be interchangeable,
> 
> Name me a few.

I can name a bunch, including some where UfW comes out ahead:

1. The Cygwin solution has some fatal flaw, either due to a missing POSIX facility in cygwin1.dll or an attempt to bypass the DLL, going straight to the Windows API under Cygwin, which results in mismatched semantics.

One such example is the recent complaint thread about Git’s path handling, which wouldn’t even come up under UfW, because it isn’t Windows at all.  Git under UfW has exactly the same semantics as under Linux, where presumably the semantics are perfect, since Linux is git’s natural environment.

Another example is CRLF and UTF-8 handling.  Any program running under Cygwin that bypasses its POSIX interfaces (e.g. calling ReadFile() instead of read(2)) will likely do strange things with LF-terminated UTF-8 text files, whereas a UfW binary will always assume LF and UTF-8 (or $LANG, anyway) text encoding.  Thus, all the hacks in Cygwin and Cygwin-ported executables for CRLF workarounds (e.g. Cygwin’s “text” mount option hack, the crnl-glob feature in Fossil to make it ignore CRs when determining if a file is “binary”, etc.) don’t need to exist under UfW.

Still another example is the unfortunate mismatches in Windows vs POSIX file locking semantics, as you recently noted in your recent thread complaining about another “useless” feature, Cygwin’s flock() implementation.  Again, the insides of the UfW box are completely POSIX, not Windows at all, so presumably locking semantics are Linux-native (i.e. advisory by default, rather than mandatory), too, so there is no mismatch between Windows and POSIX semantics.  Here, the wall between NT subsystems helps: you can’t have a Windows app and a UfW app fighting for lock control of a single file, since Windows apps can’t even see inside the UfW filesystem.

(You could have such a fight through the /mnt/[driveletter] door, but that’s like arguing that the availability of NFS or SMB locking prevents Linux locking semantics from working correctly.  Conflicts can only occur in the shared filesystem.)


2. Many people using Cygwin merely want a given non-portable Unixy tool (e.g. git) to work on Windows.  The choice between installing Cygwin git vs installing UfW from the Windows app store and then saying “apt install git” is a “six of one, half a dozen of the other” alternative, as long as you’re only interested in managing a Windows git tree from the command line. 

If you need non-CLI things to work, such as like git gdiff integration with, say, Beyond Compare, then of course you’d have to use Cygwin git or similar, such as the MinGW-based “Git for Windows” offering instead of UfW git.


3. You’re using Cygwin merely to give Windows an interactive POSIX userland, so you have things like grep and sed for operation on Windows filesystem objects.  The same ability to say something like “sed -i -e s/foo/bar $(grep -Rsl foo)” in Cygwin works just as well under UfW.  It works better under UfW, in fact, since the recursive filesystem search will probably be a lot faster under UfW, since all file access isn’t going through an in-userspace POSIX translation layer.

This is what I meant when I described UfW as an apology to Windows users for the complete misinterpretation of request vs intent when the PC poweruser crowd demanded a better shell and Microsoft gave us PowerShell instead of what we actually wanted, which is something more like Bash.


4. You’re using Cygwin on Windows to test software that normally builds and runs on Linux on a PC where installing Linux or a VM manager isn’t an option.  (e.g. A typical corporate locked-down desktop PC.)  Given a choice between Cygwin and UfW, both will work; UfW will probably work better, since your actual deployment environment needs ELF executables, so you can even build distribution tarballs under UfW, whereas under Cygwin, you’d have to do cross-compilation, which adds a bunch of complexity.  (Custom compilers, separate include and lib trees, etc.)

In fact, in such an environment, UfW might have a distinct advantage, being available through the Windows Store.  A typical corporate PC lock-down policy might not restrict installation from the Windows Store (such apps being pre-vetted, signed, and therefore “safe”) but might prevent installation of Cygwin, since Cygwin is third-party and doesn’t normally install on a per-user basis.


5. Anything where the Ubuntu package repo has software not present in the Cygwin or Cygwin Ports repo.  For example, the Cygwin package repo only has iperf2, which is protocol-incompatible with iperf3.  If you need to do a bandwidth test against a remote system running iperf3, installing UfW so you can “apt install iperf3” is probably easier than porting iperf3 to Cygwin and maintaining a private copy.   

(Indeed, iperf3 doesn’t build OOTB on Cygwin due to an API conflict with newlib, a problem that doesn’t impact glibc based systems like UfW.)

Plus, iperf3 measures I/O overheads, so the lower impedance mismatch between the UfW ABI and the cygwin1.dll translation layer means the benchmark results will probably be more accurate under UfW.  (i.e. A truer measure of the system’s network I/O bandwidth.)


6. A lot of Unix software runs like a pig under Cygwin due to the user-space gyrations Cygwin must go through to implement POSIX semantics under Windows.

The classic example of this is fork(), which makes a lot of software (e.g. Apache, shell scripts, etc.) much faster on Linux or in native Windows ports than under Cygwin.

Another example is anything dealing with many I/O sockets or other file descriptors, which often use poll() or epoll() on Linux for speed, relative to select(2).  Cygwin doesn’t implement epoll() at all, its poll() implementation is done in terms of select() (therefore giving no speed advantage at all) and its select() implementation doesn’t even delegate to the in-kernel Windows Winsock function select(), but instead reimplements its effect purely in user space in terms of Windows events, which are limited to 64 per user thread, purely to get POSIX semantics (e.g. select() on FD, FD passing, etc.) under Windows, things the Winsock select() implementation doesn’t provide.  All of this makes Cygwin select() much slower than Winsock select(), which in turn is much slower than more modern interfaces native to Linux and its competitors, such as epoll(), kqueue, aio_*(), and IO Completion Ports.

Still another common area of Cygwin weakness is in threading.  Cygwin’s handling of threads is a lot better these days than it used to be, but it’s still not at the level of thread handling under Linux, due to the translation layer Cygwin needs to supply to convert POSIX threading semantics to Windows semantics.  We saw this on the mailing list not long ago when someone posted a question about using C++’s native threading libraries under g++ on Cygwin, where Cygwin did something very odd that it didn’t do on Linux.  No one answered the question, apparently because so few Cygwin users really understand how Cygwin threads are supposed to work, whereas such software Just Works on Linux, where the NPTL library and its in-kernel backings (e.g. clone(2)) are highly-debugged and optimized.

Thus, the availability of UfW will be a much greater disincentive to create native Windows ports of software than Cygwin ever was.  We have things like native Apache for Windows because it simply runs so much better that way than under Cygwin, because it swaps out all the POSIX mechanisms for native ones, removing the impedance layer mismatch.  That was necessary 20 years ago when the alternative was Cygwin and all its attendant limitations.  The same will be true for anything else based on libapr, like Subversion, another piece of software that’s difficult to port to Cygwin, as I understand it.  Whereas “apt install subversion” is trivial.


7. Running “too-portable” software.

A lot of things ported to Cygwin have in-tree support for building natively on Windows as well.  (e.g. Perl.)  Often such software has “#ifdef WINDOWS” conditional code in it, so that it behaves differently when run under Cygwin than when run under Linux, because its portable code compiles instead of the POSIX alternative.  Thus, a UfW version of the same program may simply behave more correctly than a naive rebuild of the same source under Cygwin.  A true Cygwin port — where all the #if WINDOWS code is carefully rewritten so the ifdef path isn’t taken under Cygwin — may simply not be available, whereas a proper Linux binary build may be available under UfW.


8. All of us who greatly prefer installing software via a command line package manager (e.g. apt, pkg, brew, yum…) rather than a GUI (e.g. setup.exe) will probably be happier under UfW than on Cygwin.  “apt install foo” is a whole lot easier than Cmd-E, navigate to the Cygwin download folder, and click-click-click for 2-3 minutes to navigate the GUI just to install one piece of software.


9. A lot of software for Linux simply isn’t portable enough to build under Cygwin, and there is no native Windows port.  Such software may do low-level unportable things, include assembly language hacks, etc. that don’t work on Windows, so your only alternative heretofore to run such software on a Windows box was to run a Linux VM.  (e.g. Node.js, the Oracle JVM (as opposed to Cygwin’s current JVM alternative, gcc-gcj), Valgrind, etc.)


Bottom line, for many use cases, UfW might well completely displace Cygwin.

Obviously Cygwin will continue to be useful in many cases, too, as I enumerated in my original post on the -talk list in the Disadvantages section of the post.

> People always find uses for everything. Doesn't make it any
> more useful.

Again, I think you might be running into an “English as a second language” problem here.

(I wouldn’t normally complain about your use of English except for your signature, apologizing for your facility with the English language.  I am therefore taking your signature at its face value: an admission that your facility with the language is not at the level you wish it to be.)

Let’s define terms:

    useless /yōosleəs/ adj. not fulfilling or not expected to achieve the intended purpose or desired outcome.

Therefore, a thing is only “useless” if if fails to achieve intended purposes.  You can say that UfW is useless *for your own purposes*, but to claim that a clearly useful thing is flat out “useless” is simply incorrect.  There is almost nothing in the world that is purely “useless.”

I’m fine if you want to say UfW is of no use to yourself.  I’m objecting to the concept that because you can’t use it, that no one else can use it either because it is “useless.”

That is, my objection is to the absolute nature of your statement.  If you make such a statement relative to yourself and I won’t have any argument against the pronouncement.

> And they will see no issues when moving from this crap to real *NIX system.

There’s much less impedance mismatch between UfW and Linux than between Cygwin and Linux.  Therefore, UfW wins on this front as well.

Is UfW problem-free?  Certainly not.  But does it have reduced problems relative to Cygwin?  In many cases, yes.

> Always working as root? What could possible go wrong?

That’s a temporary issue, a limitation of UfW’s current beta nature.  Microsoft have publicly stated that they will be reworking it to allow it to run under your normal user’s permissions and to implement sudo before they release it to the public.

I’m sure the “everything runs as root” nature of it is for the same reason that during the bootstrapping process for any OS, you normally do everything as root.  User permission management is one of the last things you port over when bootstrapping a new OS, once all the tooling is ported over. 
--
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

Re: native Linux userland in Windows 10

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 4797 bytes --]

Note that I'm not necessarily arguing against you in every point you wrote. Some reactions are just notes.

On 21. 4. 2016 0:10, Warren Young wrote:
> One such example is the recent complaint thread about Git’s path handling, which wouldn’t even come up under UfW, because it isn’t Windows at all.  Git under UfW has exactly the same semantics as under Linux, where presumably the semantics are perfect, since Linux is git’s natural environment.
> 
> Another example is CRLF and UTF-8 handling.  Any program running under Cygwin that bypasses its POSIX interfaces (e.g. calling ReadFile() instead of read(2)) will likely do strange things with LF-terminated UTF-8 text files, whereas a UfW binary will always assume LF and UTF-8 (or $LANG, anyway) text encoding.  Thus, all the hacks in Cygwin and Cygwin-ported executables for CRLF workarounds (e.g. Cygwin’s “text” mount option hack, the crnl-glob feature in Fossil to make it ignore CRs when determining if a file is “binary”, etc.) don’t need to exist under UfW.
>
> Still another example is the unfortunate mismatches in Windows vs POSIX file locking semantics, as you recently noted in your recent thread complaining about another “useless” feature, Cygwin’s flock() implementation. Again, the insides of the UfW box are completely POSIX, not Windows at all, so presumably locking semantics are Linux-native (i.e. advisory by default, rather than mandatory), too, so there is no mismatch between Windows and POSIX semantics. Here, the wall between NT subsystems helps: you can’t have a Windows app and a UfW app fighting for lock control of a single file, since Windows apps can’t even see inside the UfW filesystem.

So far you're enumerating limitations of Cygwin-Win32 interoperability, not limitations of Cygwin. Correct me if I'm wrong, but AFAIK if you stick to (well-written) Cygwin programs and Cygwin filesystem, you don't have to work around wrong line endings nor strong locks.

> (You could have such a fight through the /mnt/[driveletter] door, but that’s like arguing that the availability of NFS or SMB locking prevents Linux locking semantics from working correctly.  Conflicts can only occur in the shared filesystem.)

I would like to make the same argument for Cygwin and /cygdrive.

> 4. You’re using Cygwin on Windows to test software that normally builds and runs on Linux on a PC where installing Linux or a VM manager isn’t an option.  (e.g. A typical corporate locked-down desktop PC.) Given a choice between Cygwin and UfW, both will work

You can install UoW without admin privileges? Or from another POV, you can install UoW but not VirtualBox?

> In fact, in such an environment, UfW might have a distinct advantage, being available through the Windows Store.  A typical corporate PC lock-down policy might not restrict installation from the Windows Store (such apps being pre-vetted, signed, and therefore “safe”) but might prevent installation of Cygwin, since Cygwin is third-party and doesn’t normally install on a per-user basis.

You're assuming LSW will become pre-installed on these workstations and UoW will become a Windows Store "app". I'm not saying it can't happen, but it seems unlikely at the moment.

> (Indeed, iperf3 doesn’t build OOTB on Cygwin due to an API conflict with newlib, a problem that doesn’t impact glibc based systems like UfW.)

Although practically speaking, Linux is more comfortable because people primarily target Linux, it'd be better to push for programs to be truly POSIX-portable instead of furthering the Linux near-monopoly.

> 6. A lot of Unix software runs like a pig under Cygwin due to the user-space gyrations Cygwin must go through to implement POSIX semantics under Windows.

Midipix could end up taking the place of the top competitor of LSW/UoW performance-wise, while retaining interoperability with Win32.

> 8. All of us who greatly prefer installing software via a command line package manager (e.g. apt, pkg, brew, yum…) rather than a GUI (e.g. setup.exe) will probably be happier under UfW than on Cygwin.

This is fixable. MSYS2 already has pacman which can do the same. (Thanks to Cygwin developers, among others.)

> 9. A lot of software for Linux simply isn’t portable enough to build under Cygwin, and there is no native Windows port.  Such software may do low-level unportable things, include assembly language hacks, etc. that don’t work on Windows, so your only alternative heretofore to run such software on a Windows box was to run a Linux VM.  (e.g. Node.js, the Oracle JVM (as opposed to Cygwin’s current JVM alternative, gcc-gcj), Valgrind, etc.)

This is definitely a win for LSW/UoW, because it goes for Linux compatibility.

-- 
David Macek


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3834 bytes --]

Re: native Linux userland in Windows 10

[John Cowan]

David Macek scripsit:

> You're assuming LSW will become pre-installed on these workstations and
> UoW will become a Windows Store "app". I'm not saying it can't happen,
> but it seems unlikely at the moment.

Why unlikely?  That is exactly what is the case, if you are running
the current alpha build of Windows 10.  

It's also worth noting that although "setup* -q -P <package>" still pops
up the familiar status display, it runs from the command line without
requiring any attention.  The only problems are the possibility of an
elevated-privilege popup (no worse than being asked for a sudo password)
and the fact that the install runs detached, so you cannot have a script
that installs something before going on unless you take special pains
to wait for the installation to complete.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
I Hope, Sir, that we are not mutually Un-friended by this Difference
which hath happened betwixt us.
     --Thomas Fuller, Appeal of Injured Innocence (1659)

--
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

Re: native Linux userland in Windows 10

[David Macek]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On 21. 4. 2016 18:01, John Cowan wrote:
> David Macek scripsit:
> 
>> You're assuming LSW will become pre-installed on these workstations and
>> UoW will become a Windows Store "app". I'm not saying it can't happen,
>> but it seems unlikely at the moment.
> 
> Why unlikely?  That is exactly what is the case, if you are running
> the current alpha build of Windows 10.  

Build #14316? You have to switch to developer mode, then install the subsystem which is a "Windows feature". Both require administrator privileges IIRC. Then you can run `bash` or `lxrun /install` to download the Ubuntu tarball, allegedly from the Store.

Until I can go to the Store app on a clean Windows install, write "Ubuntu" and click on Install, I won't consider UoW as "available through the Windows Store" as Warren Young wrote.

-- 
David Macek


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3834 bytes --]

Re: native Linux userland in Windows 10

[Steven Hartland]

On 22/04/2016 08:02, David Macek wrote:
> On 21. 4. 2016 18:01, John Cowan wrote:
>> David Macek scripsit:
>>
>>> You're assuming LSW will become pre-installed on these workstations and
>>> UoW will become a Windows Store "app". I'm not saying it can't happen,
>>> but it seems unlikely at the moment.
>> Why unlikely?  That is exactly what is the case, if you are running
>> the current alpha build of Windows 10.
> Build #14316? You have to switch to developer mode, then install the subsystem which is a "Windows feature". Both require administrator privileges IIRC. Then you can run `bash` or `lxrun /install` to download the Ubuntu tarball, allegedly from the Store.
>
> Until I can go to the Store app on a clean Windows install, write "Ubuntu" and click on Install, I won't consider UoW as "available through the Windows Store" as Warren Young wrote.
>
You also need a huge pinch of good luck as the process is flaky as hell, 
often failing to present any preview builds at all.

     Regards
     Steve

--
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

Re: native Linux userland in Windows 10

[Andrey Repin]

Greetings, Warren Young!

> On Apr 15, 2016, at 4:04 AM, Andrey Repin <anrdaemon@yandex.ru> wrote:
>> 
>>> And yet, despite the free
>>> availability of top-quality VM technology, Cygwin continues to thrive.
>> 
>> Because interoperability.

> So the ability to run native Linux ELF binaries without recompilation on
> Windows is not “interoperability”?

Following your logic, starting a Linux VM to run diff on two files counts as
"interoperability".
Not as long as I can't run them alongside native windows binaries.

>>> UfW won’t fill 100% of the use cases of Cygwin from day 1, but for a lot of
>>> cases, the two will be interchangeable,
>> 
>> Name me a few.

> I can name a bunch, including some where UfW comes out ahead:

> 1. The Cygwin solution has some fatal flaw, either due to a missing POSIX
> facility in cygwin1.dll or an attempt to bypass the DLL, going straight to
> the Windows API under Cygwin, which results in mismatched semantics.

> One such example is the recent complaint thread about Git’s path handling,
> which wouldn’t even come up under UfW, because it isn’t Windows at all.  Git
> under UfW has exactly the same semantics as under Linux, where presumably
> the semantics are perfect, since Linux is git’s natural environment.

That's unconfirmed suspicions. We haven't seen the how fork(2) implemented yet
to judge the level of "superiority".
And the git issues seems to have been fixed by repairing directory permissions.
I give you that UfW will likely not have permission issues, since it
essentially runs as "root", but this in itself is a fatal flaw, when it comes
to portability of practices.

> Another example is CRLF and UTF-8 handling.  Any program running under
> Cygwin that bypasses its POSIX interfaces (e.g. calling ReadFile() instead
> of read(2)) will likely do strange things with LF-terminated UTF-8 text
> files,

That's not possible. There's no special rules regarding LF vs. CRLF in UTF-8.
You're making things up.

> (e.g. Cygwin’s “text” mount option hack, the crnl-glob feature in Fossil to
> make it ignore CRs when determining if a file is “binary”, etc.) don’t need
> to exist under UfW.

Again, unconfirmed suspicions, and text mounts were discouraged for the last
ten years at least, on my memory.

> Still another example is the unfortunate mismatches in Windows vs POSIX
> file locking semantics, as you recently noted in your recent thread
> complaining about another “useless” feature, Cygwin’s flock()
> implementation.  Again, the insides of the UfW box are completely POSIX, not
> Windows at all, so presumably locking semantics are Linux-native (i.e.
> advisory by default, rather than mandatory),

Which means that such a lock could still be broken from another [user's] UfW
process, or a native Windows application.

> too, so there is no mismatch
> between Windows and POSIX semantics.  Here, the wall between NT subsystems
> helps: you can’t have a Windows app and a UfW app fighting for lock control
> of a single file, since Windows apps can’t even see inside the UfW filesystem.

Wishful thinking. There's no separate filesystem for UfW.

> (You could have such a fight through the /mnt/[driveletter] door, but
> that’s like arguing that the availability of NFS or SMB locking prevents
> Linux locking semantics from working correctly.  Conflicts can only occur in
> the shared filesystem.)

For all that I know, CIFS locks are managed on server, not on client.
I don't know about NFS, though.

> 2. Many people using Cygwin merely want a given non-portable Unixy tool
> (e.g. git) to work on Windows.  The choice between installing Cygwin git vs
> installing UfW from the Windows app store and then saying “apt install git”
> is a “six of one, half a dozen of the other” alternative, as long as you’re
> only interested in managing a Windows git tree from the command line. 

> If you need non-CLI things to work, such as like git gdiff integration
> with, say, Beyond Compare, then of course you’d have to use Cygwin git or
> similar, such as the MinGW-based “Git for Windows” offering instead of UfW git.

I can see it working for git, or other self-contained application.
Or an application that provide network service (MySQL, Apache).
But not for apps that have a high usage frequency and short lifetime.
I.e. diff, in my case.

> 3. You’re using Cygwin merely to give Windows an interactive POSIX
> userland, so you have things like grep

Or grep.

> and sed for operation on Windows
> filesystem objects.  The same ability to say something like “sed -i -e
> s/foo/bar $(grep -Rsl foo)” in Cygwin works just as well under UfW.

It doesn't.
To get it running in UfW, I first need to get to it somehow, and then I need
to somehow pass the paths, in case it don't grok redirects well. (In case of
diff, that's precisely the case.)

> It works better under UfW, in fact, since the recursive filesystem search
> will probably be a lot faster under UfW, since all file access isn’t going
> through an in-userspace POSIX translation layer.

That's a case I rarely use myself. I have better tools to search across the
filesystem.

> This is what I meant when I described UfW as an apology to Windows users
> for the complete misinterpretation of request vs intent when the PC
> poweruser crowd demanded a better shell and Microsoft gave us PowerShell
> instead of what we actually wanted, which is something more like Bash.

bash in itself isn't especially feature-rich. Yes, it has nice extensions, but
few people actually use more than a few of them.
What makes it seemingly so powerful is the POSIX ecosystem.
Quoting and redirection rules in particular, compounded by the set of tools
that POSIX mandates to be present.
Which makes coupling different tools together less of a pain.
In the case of UfW, this is not going to be an advantage, as it is a parallel
world to the Win32 subsystem.

> 4. You’re using Cygwin on Windows to test software that normally builds and
> runs on Linux on a PC where installing Linux or a VM manager isn’t an
> option.  (e.g. A typical corporate locked-down desktop PC.)  Given a choice
> between Cygwin and UfW, both will work; UfW will probably work better, since
> your actual deployment environment needs ELF executables, so you can even
> build distribution tarballs under UfW, whereas under Cygwin, you’d have to
> do cross-compilation, which adds a bunch of complexity.  (Custom compilers, separate include and lib trees, etc.)

> In fact, in such an environment, UfW might have a distinct advantage, being
> available through the Windows Store.  A typical corporate PC lock-down
> policy might not restrict installation from the Windows Store (such apps
> being pre-vetted, signed, and therefore “safe”) but might prevent
> installation of Cygwin, since Cygwin is third-party and doesn’t normally
> install on a per-user basis.

Corporate permissions (and social issues overall) is a topic for different
discussion.
Under normal circumstances, such issues are resolved by a simple [written]
request to the associated department, outlining requirements and necessities
to perform your daily job.

> 5. Anything where the Ubuntu package repo has software not present in the
> Cygwin or Cygwin Ports repo.  For example, the Cygwin package repo only has
> iperf2, which is protocol-incompatible with iperf3.  If you need to do a
> bandwidth test against a remote system running iperf3, installing UfW so you
> can “apt install iperf3” is probably easier than porting iperf3 to Cygwin
> and maintaining a private copy.

> (Indeed, iperf3 doesn’t build OOTB on Cygwin due to an API conflict with
> newlib, a problem that doesn’t impact glibc based systems like UfW.)

Seeing as newlib moves forward, I think that's more a question of effort,
rather than possibility.
Regardless, I got your point, and I covered it earlier.
Any self-contained application will likely success. But that's all.

> 6. A lot of Unix software runs like a pig under Cygwin due to the
> user-space gyrations Cygwin must go through to implement POSIX semantics
> under Windows.

> The classic example of this is fork(), which makes a lot of software (e.g.
> Apache, shell scripts, etc.) much faster on Linux or in native Windows ports
> than under Cygwin.

And we haven't seen the results of fork implementation in UfW yet. Or did we?
Either way, this is a guesswork, and needs real ground before any discussion
could go on in this area.

> 7. Running “too-portable” software.

> A lot of things ported to Cygwin have in-tree support for building natively
> on Windows as well.  (e.g. Perl.)  Often such software has “#ifdef WINDOWS”
> conditional code in it, so that it behaves differently when run under Cygwin
> than when run under Linux,

I'm not familiar with "e.g. Perl", so I'll give you that.

> 8. All of us who greatly prefer installing software via a command line
> package manager (e.g. apt, pkg, brew, yum…) rather than a GUI (e.g.
> setup.exe) will probably be happier under UfW than on Cygwin.  “apt install
> foo” is a whole lot easier than Cmd-E, navigate to the Cygwin download
> folder, and click-click-click for 2-3 minutes to navigate the GUI just to install one piece of software.

I don't antagonize GUI and CLI. CLI perfect when you know the result in
advance and fully expect the system to "do the right thing" (f.e.
"apt install whatever").
But when you need to visualize a complicated chain of dependencies, a nice GUI
tool, such as aptitude or synaptic, suits the job better, than console fiddling.

> 9. A lot of software for Linux simply isn’t portable enough to build under
> Cygwin, and there is no native Windows port.  Such software may do low-level
> unportable things, include assembly language hacks, etc. that don’t work on
> Windows, so your only alternative heretofore to run such software on a
> Windows box was to run a Linux VM.  (e.g. Node.js, the Oracle JVM (as
> opposed to Cygwin’s current JVM alternative, gcc-gcj), Valgrind, etc.)

And on this point, I'm HIGHLY sceptical. To make such tools work, the kernel
API needs to be implemented on such a level, that it basically becomes a VM,
nigh compatible with the rest of operating system.

> Bottom line, for many use cases, UfW might well completely displace Cygwin.

From nine cases you presented, four are arguable the variations of the other.

> That is, my objection is to the absolute nature of your statement.  If you
> make such a statement relative to yourself and I won’t have any argument
> against the pronouncement.

Certainly. My point being, if I need an isolated, self-contained application,
I chose native program for the job. Though it is long since I moved all of my
tools to dedicated Linux server. I can't possible recall any program that
stands out from general utility pack, that I can give up for UfW.
Assuming I want to install OS that blatantly spying on me, of course.

> Is UfW problem-free?  Certainly not.  But does it have reduced problems
> relative to Cygwin?  In many cases, yes.

I'd say, it have different problems, in addition to some issues shared across
both. (I.e. path conversion.)

>> Always working as root? What could possible go wrong?

> That’s a temporary issue, a limitation of UfW’s current beta nature. 
> Microsoft have publicly stated that they will be reworking it to allow it to
> run under your normal user’s permissions and to implement sudo before they
> release it to the public.

That's more the way I'd like it to be.

> I’m sure the “everything runs as root” nature of it is for the same reason
> that during the bootstrapping process for any OS, you normally do everything
> as root.  User permission management is one of the last things you port over
> when bootstrapping a new OS, once all the tooling is ported over. 


-- 
With best regards,
Andrey Repin
Thursday, April 21, 2016 17:50:15

Sorry for my terrible english...

Re: native Linux userland in Windows 10

[John Cowan]

Warren Young scripsit:

> 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'm not so sure of that.  Canonical is fairly friendly to non-FLOSS
software, although the great bulk of the distro is of course FLOSS.  
It may be a matter of who MS thought they could best work with.

> 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.

Ever since I had to switch to Win64, I've missed CoLinux (which apparently
is no longer being developed).  UoW, once the bugs are flushed, will
look a lot like that: the Windows filesystem is visible but the Win32
executables don't work.  (Wine on UoW?  Who knows?)

> 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.

There are of course a few Posix commands like that, notably ls.
It's just that we are used to them, and they usually do the Right Thing
when the output is not a tty.

> 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.

Based on my CoLinux experience, I expect I'll keep Cygwin but won't
use it as much as I do today.  It will still be indispensable for some
things.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
Not to perambulate the corridors during the hours of repose
in the boots of ascension.       --Sign in Austrian ski-resort hotel

--
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