Microsoft has open-sourced PowerShell for Linux, Macs. Repeat, Microsoft has open-sourced PowerShell Microsoft has published PowerShell, its scripting and automation platform, as open source under the permissive MIT licence, as well as porting it to Linux and Mac, with an alpha build now available on GitHub. PowerShell is built on Microsoft's .NET platform, and one of the enabling pieces here is .NET Core, the refactored fork …
Ah crap, it says it can't find that in the repository.
Well, I'm relieved... Debian/Ubuntu replaced bash with dash as standard shell (/bin/sh links to dash) for the sake of speed and memory footprint. Using a shell that has dependencies on .Net is just the opposite, and looks like a very bad idea!
Also, I want my scripts as "Posix" as possible so that I can run them on my Synology too (default script engine is ash), or when they are published, people can run them with bash if they see fit, or any other reasonably Posix script engine. And I'm not sure PS has any level of compliance to Posix: any idea about that M$ fanboys?
Why, just why?
This is of no use to Windows people, they do not use Linux, this is of no use to Linux people, we already have a number of decent functioning shells that cover many use cases.
We have a number of scripting languages that we can combine flawlessly with these shells.
Why? What problem does this solve?
I'm sure there is a psychopathic reason for all of Microsoft's Linux love and this has a dark purpose.
It may be of some surprise in your binary view of the world that in additon to "Windows people" and "Linux People" there are also "we just need to get shit done and sometimes use Windows servers and sometimes use Linux servers, depending on the job people".
Being able to take a script I already use on a Windows box and use it on a Linux box will save time. Same going the other way with Microsoft implementing Bash in Windows.
Point missed by a mile I am afraid. I am talking about powershell scripts I have already developed, in addition to the massive amount of scripts others have written. Why re-invent the wheel again?
That and the fact that I can pipe objects into the next cmdlet instead of having to worry about wrangling the output of the previous commands to get the required input for the next one.
I can easily see companies such as VMWare and Citrix who are already heavy powershell users, using it in Linux instead of writing stuff twice. For example, Xenapp/Xendesktop 7.x is completely manageable via powershell. Now they have developed a Linux VDA, this will mean they only have to write things once to target either Windows or Linux VMs. This could boost the development speed of the Linux VDA and could lead to faster uptake of Linux servers in VDI or terminal server environments.
Why? Because some of their big money products that they want to port to Linux are integrated with it, It's a dependency which they have to bring along with the stuff they do want.
I imagine that somewhere there's a Gantt chart showing what's required to get certain important products onto Linux instances in MS Azure cloud, and PowerShell is just one of the milestone dependencies.
I seriously doubt that they're doing it just because someone thought "wouldn't it be cool if PowerShell ran on Linux?" Somewhere there's a business plan, and this just happens to be one of the minor tick-boxes to make the plan work.
The "object oriented shell" thing has been done on Linux before, years ago. Nobody was interested because it just didn't solve a problem that anyone had. Bash did the simple shell stuff, and it was something that admins (as opposed to software developers) could work with.
For advanced scripting there was Perl, and later Python and Ruby, all of which were full fledged programming languages with good integration with the OS, and an absolute ton of libraries to build on as well. The big management systems such as Ansible, Salt, etc. are built on Python and Ruby.
Nobody in the Linux field is going to care the slightest about PowerShell, except as a dependency that will get installed along with some Microsoft "enterprise" product. And I don't think that the people inside Microsoft who are making these decisions seriously expect it to be any other way.
If I was the secret tippy-toe bit of the state then I would try to inject my weasely nose inside somewhere that cynical folks wouldn't expect me to; like one of the open source projects or their supporting companies. Are you sure you trust them? Of course, being open source, its harder to put sneaky stuff into code but not impossible, and there are other things they can do, not least figuring out who all the trouble makers are and keeping a closer eye on them. Are you sure you trust Linus? He is a bit authoritarian?
I guess another way to do things isn't a bad idea, but if the main benefit of powershell vs. the "old" Linux way of doing things is that it works on objects then why not just move everything to JSON or XML instead of the plain text used now?
Config files will still be easily human readable/editable, current utilities only need to be updated to read/write whatever format is chosen and, perhaps, a new way of passing arguments to programs implemented (to save all the escaping/argument length issues - maybe some form of shared-memory mechanism). This way any shell can implement features to manipulate the objects since they're just formatted text to start with.
DTDs, or something for the same purpose, could be provided to easily validate the object text and ensure type-safety and such via a simple library which ensures everything is correct and is exposed in the scripting language of the shell.
It's all just serialisation with enforced rules, seems a much better solution all round than having to port all the .Net stuff.
I think it's good news if they'll port it to Solaris and so on too. I'm a DBA supporting dbs across Solaris, Linux, AIX and Windows. At the moment our scripts are a mix of bash, perl, Python and Powershell. We have a lot of scripts we need to run across all those environments and Powershell has very good database integration. We'd definitely use it if the Unix/Linux versions work well.
when I remember reading Microsoft posts on Usenet in 1982.
Folks seem to forget they were the largest Unix... UNIX... whatever it was at the time, licensor (OK, technically, XENIX, but it was still Unix) in the mid to late 1980s.
http://www.microsoft.com/billgates/speeches/industry&tech/uexpo.asp
Of course, Gates had to rewrite and extend The Road Ahead having famously underestimated the WWW. I remember thinking how odd that was see as they were active on the Internet way before the web was the web.
Cool! I look forward to seeing how things develop.
Good times. :-)
We are all technicians, for every job you pick the tool or toolbox, use it, complete the job and put it back. If powershell lets me do a job quicker with less hassle then I'll use it.
If only we could see microsofts 10 year plan, containerised AD, exchange, sharepoint, SQL server? No OS at all, everything running as unikernels? Everything cloud, office data centres converted into toilets. If you want to be relevant in that world then MS's recent efforts such VSCode, .net, SQL server and now powershell all makes sense.
The coffee is brewing, for fucks sake wake up.
On the current job, I've encounted powershell - for a couple things in W2k12 and SQL 2k12 that should've been easily configurable, but for some reason, they were not... I downloaded some other people's scripts and wrote one or two (simple ones) of my own.
Seems to me that the syntax of Powershell is a little uncertain / not strict in one particular style / confusing to me.
Powershell is more confusing to me than Perl syntax, and yes I do mind the Perl's multiple ways of doing the same thing, the boundary between Perl 5 "canonical best practices" and the mess supported for backward compatibility with Perl 4 and older...
I'm actually using Perl on Windows for slightly more complicated scripting, things that exceed the capabilities of cmd.
Sarcasm off this time - I only dare being sarcastic as an AC (not when logged in).
You might be surprised at what you can achieve with CMD and the build in commands for manipulating AD, DNS, DHCP, etc.
We run up standardised environments for our clients. When we get a new customer, I just need to clone some template VMs and turn them on. When they startup they ask for a few parameters such as domain name, subnet. Once I supply these I go for a coffee break.
When I get back, I have a complete AD environment with all DNS zones and DHCP scopes set up. Required security groups and base set of users set up. Base set of applications on the RDS servers. Pretty much all I have to do is install any bespoke apps the client needs, import a CSV of users, setup any other client specific configuration and they are ready to go.
All done with CMD scripts. I haven't got round to re-writing them in powershell yet.
Why do so many view this as a "Good Thing"(tm)? MS is known to be anti-Linux, anti-freedom, and anti-standards. This is just another attempt by them to poison and destabilise Linux.
Once admins start to use PowerShell in anger, MS will add proprietary Windows-only extensions or deliberately break things on Linux (as they have already done with curl and wget).
People should totally reject this as the toxic poison it is from the malicious entity of MS.
Microsoft, like every other BigCorp is not anti anything they are simply pro money. They make money from Linux VMs running in their cloud so they want to support it.
Under Ballmer they saw Linux as a threat to Windows sales so made life hard. Things are different now.
The desktop (and to some extent, the server) OS wars have come and gone. MS are looking at a different future where you pay them to run your VMs on their tin and they don't give a shit what OS is running on them.
Same with SQL server. Whether you run it on Windows or Linux you still give them money for the licenses.
You appear to be under the mistaken belief that MS do things for ideological reasons. They don't, they just want your money.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
