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!!!
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.
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
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...
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.
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.
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.
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.
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.
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.)
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.
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]