JeffreySnover

Step by step we've been doing more and more focused on Linux users. If you take a look at our telemetry - it is clear something is working because Linux usage is through the roof!!!

https://aka.ms/psgithubbi

I don't want to make any news here but in a bit, the team will publish a blog articulating where we'll be focusing our next release. I think you'll like the direction we are taking.

Jeffrey Snover [MSFT]

Those youngings probably don't remember what the Germans and Japanese did in the 40's either.

Or the good old day's when Ultrix ran like a racehorse on 4MB of ram (it did BTW!).

We don't do our credibility any favor when we live in the past and don't update our worldview based upon current facts.

Jeffrey Snover [MSFT]

That's not quite right. We have always focused on CUSTOMER success.

You are right that there is self interest in that (as Satya likes to say - it is hard to be successful if your customers aren't succeeding) but the PowerShell team has NEVER been confused about what the high order bit is.

Without going down the rabbit hole, I'll just point to the fact that our launch partners for PS Core were: - AWS - GCE - VMWARE

Jeffrey Snover [MSFT]

There are enough examples of companies doing terrible stuff that concerns are entirely understandable.

Let me take the opportunity to say:

1) YOU ARE NOT OUR PRODUCT! 2) Our goal is to use telemetry to help us make better decisions about what will help our customers (as with with projects, only a subset of users are active in our community feedback process) 3) We are super open about the telemetry (including going through the PowerShell community review process) and publish all the data. More details here: https://devblogs.microsoft.com/powershell/new-telemetry-in-p...

Here is all the telemetry: https://aka.ms/psgithubbi

Jeffrey Snover [MSFT]

Process creation on Windows has always been significantly slower than Unix. That is why PowerShell is skewed towards "built-ins" vs launched applications. The ramification of that is slower startup times.

Interesting note - it is also the reason why PowerShell was able to adopt the more natural Verb-Noun model for cmd naming. In Unix, this would produce a huge # of files OR and you couldn't do "VERB NOUN" because then you would have to multiplex on the VERB. Unix's "NOUN VERB" is the result.

BTW - VMS DCL stepped on all these rakes which is why it is have VERB/NOUN and half NOUN/VERB. A complete mess.

Jeffrey Snover [MSFT]

If you have modules in your module path that don't declare their exports in the manifest, PowerShell has to inspect everything to find all the cmds. This is often what is going on when you have terrible startup times.

The second half of the quote is, “but sometimes it takes us a couple decades to get right”. :-)

Seriously though, have you checked out the search in O365? It is starting to get really good and wait till you see how this progresses in the next couple of years.

I think I’ll be proven right. :-)

We thought about that but the reality is that it does not work well for interactive experiences.

When you look at how admins get their job done, it starts in the interactive shell and then when the do things frequently, they put it into a simple script and when then need it to be more formal, they invest in making it production quality.

That is the flow that PowerShell was designed to support.

Jeffrey Snover [MSFT]

Syntax is like ice cream. Some people like vanilla. Others like chocolate.

Jeffrey Snover [MSFT]

PowerShell was designed to provide a very wide dynamic range of capabilities from interactive actions to simple ad hoc scripts to more formal programming. The goal was to have a single tool that admins and programmers could share to create and manage systems where they could pick how formal they needed to be to solve the problem at hand and can simply modify (vs replace) it as the solution need to be by more people or more production scenarios.

Jeffrey Snover [MSFT]

That is correct (prevent accidental script execution).

It is ABSOLUTELY NOT a security mechanism. That is why we we support this:

Set-ExecutionPolicy -ExecutionPolicy Bypass

I wanted to make it:

Set-ExecutionPolicy -ExecutionPolicy DoAnythingBecauseTExecutionPolicyIsNOTASecurityFeature

But the team didn't like that. (I should have overruled them on that one :-) ).

Jeffrey Snover [MSFT]

Yikes! - you shouldn't have to do Set-ExecutionPolicy every time you start a shell. Something is definitely wrong there.

Try doing a: Get-ExecutionPolicy -List to see what is setting it.

Then use -SCOPE on Set-ExecutionPolicy.

BTW - I hear you on the "only chmod the scripts you want" - that is a nice benefit of the Unix model.

Jeffrey Snover [MSFT]

That was the approach I took before inventing PowerShell. We didn't WANT to invent a shell - we were forced into it.

The problem was that Bash on Windows wasn't effective. At the heart of the matter is the difference in architecture between Unix and Windows. In Unix, most everything is a file so if you can modify files and restart processes, you can manage everything. In Windows, most everything is an API so tools that manipulate files don't do much for you.

Ergo - we needed an admin automation model which supported an API oriented architecture. Thus PowerShell.

NOTE - Bash on Windows today has a very different focus - it is not about managing Windows (which it still doesn't do) - it is about using OSS tools to develop OSS Software. It does a great job at that.

Jeffrey Snover [MSFT]

Here is how you do that:

$PSDefaultParameterValues["Out-File:Encoding"]="utf8"

Jeffrey Snover [MSFT]

That is right.

CMD.exe will be around to support script execution for a long long time.

Jeffrey Snover [MSFT]

Major improvements in V5.

Even more in V5.1 (which ships with WS2016).

But still slower than CMD.

CMD starts very quickly but then you have CMD. :-)

Jeffrey Snover [MSFT]

I've never quite understood the concern about needing to Set-ExecutionPolicy before running scripts.

In Unix, you have to chmod a+x a file before running it. And you have to do it for every script you want to run.

So to run 1 cmdlet to enable all scripts seems a bargain. (Honestly I could be missing something and I probably am because you are not the first person to mention it. I just can't connect the dots.)

Jeffrey Snover [MSFT]

That is a good tip. There are certain product teams that produced ENORMOUS objects and your suggestion helps when dealing with that.

Jeffrey Snover [MSFT]

We are incapable of sustained error. 25+ years was enough. :-)

Jeffrey Snover [MSFT]

Sorry about that - we lost control of our startup times in PS V3 and have been working to get it back under control. PowerShell V5 had substantial improvements but we keep working on it and V5.1 is even faster. Give it a try - I think you'll like it.

Jeffrey Snover [MSFT]

FYI - we don't charge for PowerShell.

Jeffrey Snover [MSFT]

That is how we got started on this. We didn't want to invent anything here. We had a technology called Services for Unix which provided all the shells and utils and I got 99.5% of the way to getting that shipped natively in Windows but it got hung up over IP concerns. So we made it free instead.

It turns out it didn't help managing Windows at all.

The heart of the problem is that Unix is a Document-oriented OS and Windows is an API-oriented OS. In Unix, if you can edit a file and restart a process - you can do most management tasks. Therefore text processing utils like awk, sed, grep are actually management tools. When these became available on Windows - they didn't help manage anything because awk didn't work against the registry, sed didn't work against WMI, grep didn't work against Active Directory. An API-oriented OS needed an API-oriented solution.

That is why we HAD to invent PowerShell. I believed that the Unix automation model was fundamentally correct: Interactive shell composing small tools together in ad hoc ways to quickly construct novel solutions to novel problems. I like to call this the " A | B | C" model.

I did a deep rethink of the "A | B | C" model and asked myself the question WHY? Why not just type A? Why didn't A do what I wanted it to do?

There is the traditional answer about toolchest of tiny tools but I keep chewing on it and came up with a different answer:

  A tightly binds 3 steps into 1.  It

   1) Gets a set of objects

   2) Processes those objects

   3) Outputs those objects (typically as text)

When when we say A doesn't do what I want it to do, what I'm REALLY saying is that A did one of those 3 steps in a way I didn't want. So piping the results to B and C is REALLY all about taking the text and reverse engineering my way back to the original objects to do one of the steps differently.

My observation was that the pipeline should go between the 3 (smaller) steps and that the pipeline should pass objects and only output to text when you wanted text.

This object orientation is one of the great simplifies of PowerShell. It allows us to shift our focus from the mechanics of text parsing to the semantics of what I want to achieve. We like to call this THINK, TYPE, GET.

THINK about what you want.

Type it

Get it

Imagine you wanted to get all the processes whose workingset was greater than 5mb and sort it by workingset and then format that as a table just showing the name the id and the workingset - in PowerShell, you would do that with this:

PS> Get-Process | Where workingset -ge 5mb |sort workingset | format-table name,id,workingset

some people complain about the verbosity of PowerShell but that is there for scripts. We have lots of aliases for interactive use. Here is an equiv:

PS> gps|? workingset -ge 5mb|sort workingset|ft name,id,workingset

So that is the answer - a lot of the great Unix tools don't work on Windows because it is an API-oriented OS. So we had to develop an API-oriented automation model - that is PowerShell.

Jeffrey Snover [MSFT]

We have a hotspot compiler.

We have talked about having it create a stand-alone executable but it has always fallen below the cut line.

Jeffrey Snover [MSFT]

Everyone has a family to feed right? There is no shame in trying to make money.

Satya was super clear on this point - he told us to get out of our offices and go talk to customers and find out what they needed to be successful. "Don't worry about the money - if you are making customers successful, we have smart people that can figure out how to make money".

To the all the engineers in our company - that was music to our ears!

I understand your skepticism but there is a new Microsoft at work here.

Jeffrey Snover [MSFT]

Yes but I think the better solution is to fix the alias problem and then work with Daniel to make it super simple for people on Windows to get his latest/greatest bits. I've reached out to him to start that conversation.

Jeffrey Snover [MSFT]

Fair feedback - we are in learning mode.

Jeffrey Snover [MSFT]

When I had no customers - I had lots of flexibility.

PowerShell is now installed on many hundreds of millions of machines.

With great success comes great responsibility.

We can and will change things but we have to do so in a thoughtful manner.

Jeffrey Snover [MSFT]

Interesting hypothesis! I'll ask Bill the next time I see him.

Jeffrey Snover[MSFT]

There are lots of aliases for cmdlets for exactly this reason - interactive use. The verbose commands are useful when reading a script that isn't working at 3am in the morning when your boss is breathing down your neck to fix it "stat!".

RE - your aside '\' vs '/' - I think most of us still shake our head at that decision.

Jeffrey Snover [MSFT]

I take a super utilitarian view. At the end of the day, PowerShell on Linux is another tool in the toolchest.

PowerShell has a POV about abstracting gorp into high level task oriented abstractions, object pipelines, structured data, and the workflow from interactive shells to ad hoc scripts to formal scripts to production scripting.

That is what a number of people are looking for in their tools and that is why they like PowerShell.

We are constantly looking for ways to improve PowerShell and make it more useful so I'd encourage you to suspend disbelieve long enough to kick the tires. If you see some stuff you don't like, I would be very interested in hearing the details. You don't need to be polite in your feedback but I'd ask you to be specific so that I can identify potential changes.

If you are happy with your existing tools - happy days!

Thanks!

Jeffrey Snover [MSFT]