5 ms·

Is there anything preventing Microsoft from putting a Linux shell natively on Windows? I'm sure PowerShell is awesome, but the DevOps person in me is not excit

by joeblau 10y ago

Is there anything preventing Microsoft from putting a Linux shell natively on Windows? I'm sure PowerShell is awesome, but the DevOps person in me is not excited at all.

jaykru 10y ago
Not quite what you're looking for, but arguably better: https://msdn.microsoft.com/en-us/commandline/wsl/about https://msdn.microsoft.com/en-us/commandline/wsl/about Been playing with it ever since I got a new Windows laptop for college (I usually would have installed Debian but I prefer OneNote to notetaking apps on available on Linux). The interesting part is that it's not a VM; the LoW subsystem translates Linux syscalls to Win32 ones
guitarbill 10y ago
this x100. i wish they'd work on chef/puppet/ansible/salt support instead. probably never going to happen though, so much functionality in windows isn't available from the command line.
- jodrellblank 10y ago
  Yeah, probably never happen. You'd never see J. Snover the 'father of PowerShell' at ChefConf last year talking about PowerShell Desired State Configuration (DSC) and its support for Chef (https://www.youtube.com/watch?v=Gh9zfm5gVEg https://www.youtube.com/watch?v=Gh9zfm5gVEg) or two years ago the PowerShell team announcing a DSC Cookbook for Chef (https://blogs.msdn.microsoft.com/powershell/2014/07/29/chef-with-powershell-dsc-now-public/ https://blogs.msdn.microsoft.com/powershell/2014/07/29/chef-...) or last year announcing Puppet's announcement of support for PowerShell DSC ( https://blogs.msdn.microsoft.com/powershell/2015/10/06/desired-state-configuration-puppet/ https://blogs.msdn.microsoft.com/powershell/2015/10/06/desir... ) You know that the entire point of PowerShell is to make Windows functionality available from the command line, for centralised management and configuration, for automated provisioning on Azure, right?
  - guitarbill 10y ago
    I think we have different definitions of support. What constantly amazes me is how similar many OSes are - except Windows. DSC hasn't changed that, even though Mr. Snover is a very clever guy. If you're in a homogeneous environment, DSC is probably great. But it's 2016, and environments are heterogenous. Even shipping an SSH client and server with Windows would go a long way as far as interop goes - which may be happening AFAIK (OK, I admit I love SSH, but it's so useful). PowerShell feels a lot like the xkcd n+1 standards thing. I don't use bash any more, but it (along with ash/dash) is the de facto standard. Sorry I can't get more excited about this, which is especially sad because my background is QBasic -> VB -> C#.
JeffreySnover 10y ago
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]

by joeblau 10y ago

Is there anything preventing Microsoft from putting a Linux shell natively on Windows? I'm sure PowerShell is awesome, but the DevOps person in me is not excited at all.

jaykru 10y ago

Not quite what you're looking for, but arguably better: https://msdn.microsoft.com/en-us/commandline/wsl/about https://msdn.microsoft.com/en-us/commandline/wsl/about Been playing with it ever since I got a new Windows laptop for college (I usually would have installed Debian but I prefer OneNote to notetaking apps on available on Linux). The interesting part is that it's not a VM; the LoW subsystem translates Linux syscalls to Win32 ones

guitarbill 10y ago

this x100. i wish they'd work on chef/puppet/ansible/salt support instead. probably never going to happen though, so much functionality in windows isn't available from the command line.

jodrellblank 10y ago
Yeah, probably never happen. You'd never see J. Snover the 'father of PowerShell' at ChefConf last year talking about PowerShell Desired State Configuration (DSC) and its support for Chef (https://www.youtube.com/watch?v=Gh9zfm5gVEg https://www.youtube.com/watch?v=Gh9zfm5gVEg) or two years ago the PowerShell team announcing a DSC Cookbook for Chef (https://blogs.msdn.microsoft.com/powershell/2014/07/29/chef-with-powershell-dsc-now-public/ https://blogs.msdn.microsoft.com/powershell/2014/07/29/chef-...) or last year announcing Puppet's announcement of support for PowerShell DSC ( https://blogs.msdn.microsoft.com/powershell/2015/10/06/desired-state-configuration-puppet/ https://blogs.msdn.microsoft.com/powershell/2015/10/06/desir... ) You know that the entire point of PowerShell is to make Windows functionality available from the command line, for centralised management and configuration, for automated provisioning on Azure, right?
- guitarbill 10y ago
  I think we have different definitions of support. What constantly amazes me is how similar many OSes are - except Windows. DSC hasn't changed that, even though Mr. Snover is a very clever guy. If you're in a homogeneous environment, DSC is probably great. But it's 2016, and environments are heterogenous. Even shipping an SSH client and server with Windows would go a long way as far as interop goes - which may be happening AFAIK (OK, I admit I love SSH, but it's so useful). PowerShell feels a lot like the xkcd n+1 standards thing. I don't use bash any more, but it (along with ash/dash) is the de facto standard. Sorry I can't get more excited about this, which is especially sad because my background is QBasic -> VB -> C#.

JeffreySnover 10y ago

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]