World, upside down? When is what? Why the who?
WHICH FOR WHERE? *explodes*
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 …
I'd rather not imagine that if it's all the same to you.
'bout as bad as imagining Margaret Thatcher naked on a cold day.
There is no amount of money in the world, not even all of it, that could persuade me to click that link.
It's the 'Extend' portion of 'Embrace, Extend, *EXTINGUISH*'
I predict WHOLESALE REJECTION of this nonsense, mostly because it's ".Not" under the hood. because if ".Not" is adopted as part of Linux, guess what's next? That's right, the same kind of ADWARE, SPYWARE, and TRACKING you get with Win-10-nic.
queue borg-speak "We will add your distnictiveness to our own. You will be assimilated. Resistance is futile"
I mean things like systemd aren't inventions by Microsoft, they are inventions by people who have never experienced the elegance of a simplistic system, people who design their software for weird edge cases that never happen. It only makes sense to do everything to keep those people from learning about the UNIX philosophy. The potential goal is of course to turn the operating system market into something like the browser market, where you have a small oligopoly of vendors which can easily cooperate against the will of the user.
Then of course there's the even simpler explanation that software running on only one platform is kinda seen as irrelevant these days. I wonder how usable it is without the rest of the operating system. After all it does not just simply pipe around text as unixoid shells do.
I think that this is part of the general plan they have for virtualisation and true portability.
They are going from the proprietary model to the open model albeit with very small steps. This nall helps so that they can attarct a bigger market share.
Who would have thunk <snip> it?
If they're Windows admins forced to use Linux once in a while?
If I had a Powershell script that needed to be ported to Linux, rather than learn Powershell to port it to bash I'd first try installing Powershell on Linux (when it is polished) to see if it provided an easier way.
You're in for a nasty surprise, what makes you think that it does integrate well in Linux? This was designed in a Microsoft centric way.
To control an application from powershell you require to have an interface with it provided by the company who made the software.
Also, I wonder what type of Linux sysadmin is going to deploy this on a Linux server to do anything just because someone feels comfortable with powershell syntax.
"To control an application from powershell you require to have an interface with it provided by the company who made the software."
Nonesense. Normal command-line invocations are possible too. If you want to make the effort, it is possible to write a cmdlet that makes the command appear powershell-native, but it is by no means a requirement.
"If I had a Powershell script that needed to be ported to Linux, rather than learn Powershell to port it to bash I'd first try installing Powershell on Linux (when it is polished) to see if it provided an easier way."
The problem with that is that shells are designed to string together existing ecosystems. Without the ecosystem the whole thing is useless.
If I had a Powershell script that needed to be ported to Linux, rather than learn Powershell to port it to bash I'd first try installing Powershell on Linux (when it is polished) to see if it provided an easier way.
It's a MS bastardisation of a MS product. It's not likely to ever be a "polished" product (look at Windows, all these years and they still haven't got it to a proper usable state! (though 7 was a good effort). And if they do "polish" it, it'll still be nothing more than a shiny turd.
(Toss up.. Linux, Troll or Joke icon... Meh.. )
"Not sure I understand why anybody would use this in preference to sh, bash, dash, csh, ksh, zsh, et al."
Hah, totally unsurprised by the downvotes, but this was exactly the first question that popped into my head. Sure, bash is a bit byzantine and most others are in declining use etc, but there it is.
Maybe the obvious answer is "because you already know it from windows and you're new to linux" but that's not it. The real answer is that you need both powershell and systemd to convert linux into windows.
And the answer is in the title of Mr Spencer's book. PS uses objects, Linux and the older Windows command line use regular expressions. The latter is easier to learn, more intuitive. I have heard Monad lovers go on about how much more powerful it is, but except for things designed specifically to be run by it, I can do anything with CMD that you can do with PS and probably get the job done faster.
So to me the choice ought to come down to which you prefer and the issue I have is that MS is working hard to remove that choice for its Windows using customers.
What is really funny though, is that since version 1 of Powershell, if you typed in a Linux shell command, it also worked, providing there was an equivalent feature in windows.
Couple of quick tests..
PS C:\Users\d> ls -la
Get-ChildItem : A parameter cannot be found that matches parameter name 'la'.
PS C:\Users\d> ssh
The term 'ssh' is not recognized as the name of a cmdlet, function, script file, or operable program.
Ok, so logging in to remote systems via SSH and listing directory contents may not be common things in Windows. Maybe traceroute? Surely even Windows can do something like that now?
PS C:\Users\d> traceroute
The term 'traceroute' is not recognized as the name of a cmdlet, function, script file, or operable program.
Windows has support Linux command line commands since Vista, in powershell.
Not quite, it seems.
(Hopefully not so tired that I've missed something in your post?)
"you need both powershell and systemd to convert linux into windows."
one way to resist (if you're running systemd now):
sudo systemctl enable multi-user.target --force
sudo systemctl set-default multi-user.target
(ignore the warnings and messages)
after that, you'll boot into console mode and need to *gasp* type 'startx' to get the GUI.
sudo systemctl enable multi-user.target --force
sudo systemctl set-default multi-user.target
(ignore the warnings and messages)
- On my system (Archlinux), all I need do is:
sudo systemctl disable <whatever display manager I happen to be running, currently sddm>.service
after boot, or additional stop command as above and logout, hey presto, console....
It's in the article. Whilst I've never gotten on with powershell it's got an awful lot of nice structured features that make the standard Unix shells looking like what they are - a 1970s solution in need of update.
Imagine doing a http request to 169.254.169.254, grabbing an access key and spawning a worker process. Sure you can do that in bash by calling curl and parsing the result but it's so much neater in powershell.
(I'm now going to get down voted by the MS haters and the cloud haters as well as the Unix greybeards!)
I don't know, in my mind when I need to do something like that, I graduate from shell to Perl/Python, and do it there.
Yes, Unix shells are old (although still being refined and developed, so today's shell is not your granddaddies), and some people don't like the design, but to be honest. They do what they say on the tin, and they do it damn well.
I can hack something together in bash with curl to do what you want, but chances are that if I had to do something like that, I would branch out into the above mentioned programming languages, do what needs to be done, and pass it back to the shell.
I don't see a need to shove everything and the kitchen sink into the shell. If I wanted that, I would basically just change my login shell from /bin/bash to /usr/bin/ipython, and have at it.
I see no reason for PowerShell on Linux. It would have been worth for me if it allowed you to run windows powershell scripts unaltered on Linux/Unix, like you can with Python/Java, however I don't get the impression that it works like that.
So, really for windows admins that have to admin the odd Linux/Unix machine and don't want the hassle of learning a Unix Shell. One serious niche, but who knows, maybe it will grow.
not used ksh93 network abilities have you ? Limited but there.
Thank $DEITY I leave this borging behind as I approach decommissioning. In older times I used Putty plink to run unix jobs from MS servers in the very few cases where that was required by business process. Felt weird using MSdog to fire off unix commands remotely, but it worked so customer was happy.
" Whilst I've never gotten on with powershell it's got an awful lot of nice structured features that make the standard Unix shells looking like what they are - a 1970s solution in need of update."
It does, until you get neck deep into it and realize it's still full of sharp edges and half-baked ideas. While there are things that make it LOOK like a true programming language, you eventually realize that's just shiny-shiny, and it's really just an overly complicated shell, or worse, just a bunch of loosely bound together common commands with a bit of looping, branching, and variables thrown in. And, in truth, it is relatively restrictive. You can only do the things that Microsoft thinks you need to be able to do, and (mostly) in the ways Microsoft thinks you should do them. At first, you don't notice these walls so much, but get further into it, and they become much more apparent.
It is an improvement over the venerable DOS shell, however. Import-CSV is worth its weight in gold and is the primary driver for using powershell at all, IMHO.
I'm sure the clean-shaven MS fanbois will apply the appropriate number of downvotes to this post. Fire away, guys.
Imagine doing a http request to 169.254.169.254, grabbing an access key and spawning a worker process. Sure you can do that in bash by calling curl and parsing the result but it's so much neater in powershell.
No, no, that is completely counter to the Unix philosophy of chaining small tools that do just one thing really well, like curl... oh, wait a minute...
It's an open secret that when MS converted the Hotmail front-ends from BSD to Windows 2000 (what, over 15 years ago) and post-mortemed the project, one (among several) clear shortcoming was the scripting capabilities. Geoffrey was already toying with an interpreted, scriptable .NET language, and the HM experience was one of the drivers to make it into a product. Take the existing shells, superset them and apply to Windows.
As an extremely long time Microsoft hater (back to the day when they abandoned OS/2), I welcome PowerShell on Linux -- especially that it is open source.
This will be another useful way to make it easier for Windows people to support Linux. It is the evil mirror universe version of my approach to dealing with Windows - which is to use cygwin, bash, and ssh.
The ability to have configurable pipe formats is pretty cool too.
But even though Windows admins might be used to PowerShell on Windows, they'll be used to using Windows commands. Linux doesn't use the same commands so those Windows admins are still going to have to learn the Linux CLI commands and all their options, etc, and the sequence they need to be run in, in order to get anything done on Linux.
@gv = "Not sure I understand why anybody would use this in preference to sh, bash, dash, csh, ksh, zsh, et al."
I suspect it's not about getting people to use PowerShell in preference to bash. There's really nothing to attract Unix/Linux users there. PowerShell isn't really a "shell" in the way that Unix users are used to thinking as it's far too verbose.
Rather, I suspect that it's part of their plan for porting more of their bread and butter applications from Windows to Linux in order to run them as part of their "cloud" product. Supposedly, PowerShell has been knitted into their other server application product lines, which means that they now have a dependency on PowerShell. Porting those server applications to Linux without leaving too many holes requires porting their dependencies as well.
Microsoft is looking to the future, and the future isn't MS Windows.
I seem to remember something about Ms envisioning Windows as a client desktop OS only at the time and Xenix was to provide the networking, as it was DOS + windows, this was a sensible vision - where did the madness and egoism creep in? I'm now forced to wonder...
Because it's an excellent shell system. Consistent, well thought through, object oriented, and works well with dotNet.
Maintaining the Windows NT kernel used to confer an advantage to Microsoft. As the profit drains out of Windows and on-site software, you will see Microsoft first open source the kernel, then dump it because it's millions of dollars in development costs that they can do without. The first step to dumping that cost source is to get all their dev's on GNU/Linux using familiar tools like VS, Powershell and SQL Server. When MS is charging you per second to use their cloud systems, there is no point in stopping the the tidal shift to FOSS operating systems.
>Because it's an excellent shell system. Consistent, well thought through, object oriented, and works well with dotNet.
That may be true but other factors are involved:
1. Open source is pointless unless the community is happy to pick it up and run with it. "Open source but only developed by MS" leaves users just as exposed to fickle business strategies as closed source does. They don't even do their own voip solution for their own phones. What's the chance of them having a vested interest in unix administration?
2. A wrapper for crontab is all very well, but its still a windows wrapper for a unix tool. Who's going to rely on that having a future? Unix people won't - they won't trust powershell to be on all unix systems. Windows people still need to learn the wrapper for cron - a unix tool. Could the skills gap be fixed in a better way by adding a "this is the format of crontab" comment at the top of the crontab file?
3. Different distros do things differently. Does updating /etc/resolv.conf directly mess with how Yast works? Do we think MS is going to keep pace with all the distros and their updates, or will this tool quickly fall to bitrot? The use-case appears to be "administering some bits of unix from windows." I'm not sure "some bits of unix" administration is enough to make the project worthwhile.
4. MS control many of the apps running on Windows servers and they can powershell-ise them. What happens when you don't control the applications? You're back to text output and parsing that using regex's and so on. The point about scripts is that you can edit them and update them to suite changing needs. The point of powershell is to remove that requirement - and that skill - and place it in the hands of the powershell developers. Powershell is a typical windows application. It does what it does well, but extending it at a sysadmin or user level, rather than developer level. is almost impossible. Can you pass powershell objects to something other than powershell? Maybe, but you'll still need the "other" skills, so your net gain is very small.
Of course, if systemd et al is the way of the future, swapping text for binary formats, much of the unix advantage of simple human-readable formats will be lost anyway. Yeah journalctl, I'm looking at you with malice.
@P. Lee - "Who's going to rely on that having a future? Unix people won't - they won't trust powershell to be on all unix systems."
Not just "won't" rely on it, but rather "can't" rely on it. Linux runs on a far greater range of hardware than MS Windows. As a result, core parts of the operating system have to work on hardware and in situations and under constraints that people at Microsoft have never heard of, let alone test or support. Therefore, PowerShell can't be a core dependency for most serious distros. It can only be a non-core optional package, which few people will bother to install.
@P. Lee - "MS control many of the apps running on Windows servers and they can powershell-ise them. What happens when you don't control the applications? "
It will only ever be of interest to companies, such as Microsoft, who already have "powershell-ised" applications that they wish to port to Linux from Windows. These will typically be proprietary "enterprise" applications. If you don't use that application, then there's no reason to install PowerShell.
In other words, don't think of PowerShell as something you would install for its own sake. Rather, it's just something that would get pulled in along with some other application.
Yeah journalctl, I'm looking at you with malice.
For me, I don't think "Malice" is quite the right word.
My Linux wouldn't boot this morning. Would only go so far then "enter root password or ^D to continue". A comment to run journalctl with some options to view the logs.
First, the logs were useless because although I have things set so that the machine does LOCAL time (which is GMT+12) the logs are stamed in UTC or somesuch. So for a long time I was hunting through tons of text looking for today's date and time, not last night when I booted the machine up some 12 hours before. Finally figured that out and started looking for the error.
Only 2 errors mentioned. One that the system couldn't start the bluetooth hardware and there was an error with it (nope, nothing wrong with it - it simply does not exist on this machine!) and the other that Windows was hibernated. So all the time wasted with journalctl when with normal logs I'm sure I would've figured out what was wrong (a quick tail or dmesg to get to the end of what I wanted to see - last few entries are usually when things break!) and then to find out (restart windows, save and close game (yes there are a couple I play in there), close windows, restart Linux and up it comes!) that the system under systemd was not booting simply because Windows was hibernated!
Sorry, unleashing in the wrong place. I should unleash both barrels at the twunts who invented systemd, and a slow-acting pain inducing poison for those who allowed it to enter the systems. Think it might be time to take a closer look at Duvian(sp - you know what I mean!) or something else.
I feel your pain ...
Systemd is a Microsoft plot to destroy Linux, along with the abhorrent abortion that is akonadi which makes modern mail clients about as reliable as a wet paper tissue in a tornado, recently kmail/akonadi decided to upgrade my e-mail data to /dev/null, not corrupted, not moved ,empty fucking directory! :(
I read the Systemd whitepaper and some of the ideas there were not that bad; But oh my god the implementation is crap, bloated and pure fucking evil
Colour me sad :(
...is that it condenses scripting through high level abstraction of something that Microsoft's toner monkeys would otherwise fail to grasp, in yet another new fucking language that I'm expected to learn for no reason other than to accommodate the aforementioned toner monkeys.
Well, you don't have to really Learn Powershell if you already know C#, as the scripting is syntactically similar. Also in powershell, as long as you remember it's always verb-noun, and you always remember Get-Help, then you can solve everything.
No-one seems to mention how powerful and useful the help system is in powershell, especially when creating help for your own custom commandlets.
Not sure I understand why anybody would use this in preference to sh, bash, dash, csh, ksh, zsh, et al.
Well, it is true that PowerShell is an extremely flexible tool when it comes to administrating Windows servers. Having the ability to easily access the registry of a remote server or its SSL keystore can be very useful.
Yet that 'remoting' as it's called is also where PowerShell shows its weaknesses. When I'm logged onto a remote server I can't simply start a commandline based text editor to edit remote files. Not because those aren't available, but because PowerShell doesn't fully support this (yet?). Not even running something as trivial as edlin can be used through PowerShell on a remote server: the very moment I start a new process then the output of that process will not find its way to me. It's unsupported!
And as we all know this is completely different for your average Unix-like console together with SSH.
PowerShell has its uses, but not so much in comparison to what you can already do on an average Unix shell.
Woohoo! Another shell!
And not only that - it's *Just* another shell. Who'd have thought the world needed _just_ another shell - it's right up there with *just* another reality TV programme, or *just* another hair care product.
Powershell for Linux / OSX - thank you MS for solving the problem that doesnt exist, for re-inventing something that isn't needed. BASH grep, awk, sed ports for Windows already exist in abundance, and lets face it most of the worlds IT now runs on some for of Unix these days (call it Linux, Android, OSX, BSD, Unix; AIX., HPUX, Solaris).
Because Windows doesn't have any ssh mechanism, and thus why they are getting slaughtered on infrastructure and cloud.
There is absolutely no benefit or reason to use Windows Server over Linux unless you are using a Microsoft specific technology such as Active Directory, Exchange, Sharepoint, etc., that doesn't run on Linux.
Combine that with the fact that Windows has been virtually unmanageable from the command line, and you can see why Linux is crushing Microsoft in the cloud arena. Powershell is Microsoft's attempt to combat this, but PowerShell is *still* of limited use because Windows has no simple mechanism for remoting into a command prompt other than Telnet, which is obviously a "hell no" to anyone who knows what they're doing, or using a sysinternals command, which is still useless if you're not connecting from a Windows machine.
I don't know why Microsoft doesn't just add SSH as a core service like so many other things, but barring that, adding SSH into powershell is a next best alternative.
Windows has always been capable of being remotely managed through an object-oriented interface which - for anyone capable of programming - is far better and robust than any script run into a shell. It turned out sysadmins are not really capable of programming (less so if the APIs are OO) and need something simpler, with which they can keep on firing in their feet. The real mess some scripted tasks is unbelievable. The world is not turning upside down, it's just stepping backwards. One day entering hex commands will be deemed the new frontier of management, just before someone proposes rotating dials and switches...
Because Windows doesn't have any ssh mechanism, and thus why they are getting slaughtered on infrastructure and cloud.
SSH is the reason that Linux is killing Windows on instructure and cloud? Please pass the crack pipe, because that's some good shit that you're smoking. And you owe me a new keyboard...
Yes, that's the issue. People continue reinventing an outdated system - Linux is an example, instead of finally getting rid of it and design something for the XXI century onward.
I believe this argument applies to virtually any existing system, including Windows. In fact, few systems are more backward compatible than Windows. If you really think that people should just always ditch what they have for something brand-new, then you're really really really delusional. Never going to happen and, more importantly, cannot happen.
"In fact, few systems are more backward compatible than Windows."
I was under the impression that various UNIX software developed in the 1970s and 1980s still builds on modern systems. The same is definitely not true for Windows.
I'm not entirely sure keeping that level of compatibility is desirable. It may just mean that computing has stagnated, as suggested in this Stack Overflow question from Alan Kay: http://stackoverflow.com/questions/432922/significant-new-inventions-in-computing-since-1980
"People continue reinventing an outdated system"
There was a similar argument on a recent thread. It set me thinking.
The Windows approach to volume handling resembles that of VMS. That in itself harked back to earlier DEC systems, as did CP/M which bore a remarkable similarity to the PDP-8's commands.
Unix got round this. Yes, it surfaced the physical volumes in /dev. But then, for most purposes, merged them into a single hierarchical file system. Although VMS post-dated early Unix its handling was clunky and anachronistic by comparison.
When MS-DOS (which, remember, was originally QDOS, a quick and dirty replacement for CP/M for 8086 and derivatives) it was made to look somewhat VMS-like, updating the PDP-8 like commands structure of CP/M. To be fair, having drive letters was reasonable enough for floppies and they were treated as flat - no subdirectories on such small devices. They even, IIRC, simulated A & B drives with a single physical drive.
When hard drives became a realistic proposition for PCs they needed to handle sub-directories and came up with a hybrid command line notation which was part VMS-like & part Unix-like. At this point they could have moved over to a Unix-like hierarchy with everything merged, inserted the floppy drives in the hierarchy as something line /mnt/a and /mnt/b and surfaced them as [A]: and [B]: for backwards compatibility. That would have enabled them to add second and subsequent hard drives quite smoothly. Maybe on the basis that a single hard drive would be enough for anybody they didn't. They added the hard drive as a C drive condemning subsequent drives to be added with other drive letters.
So now we have Windows using a clunky, antiquated system with multiple drive letters bearing a resemblance to long-gone ancestors.
Casting my mind back to my last permie job I was running Unix/RDBMS systems with a VMS-oriented IT management. The view there was never that my stuff was out-of-date. It was seen as an upstart which in 6 months time would be replaced by real computers, namely good old VAX/VMS. Always in 6 months time. Regrettably I wasn't around to see the reactions when DEC was taken over by a PC maker and then by those HP people who provided that dreadful upstart HP-UX.
So what all this got me thinking was: did WIndows servers gain their ascendency through IT managements such as those of my old employer who could no longer get their fix of old-style clunky computer interfaces and settled for the thing that came closest?
@Doctor Syntax - The reason that MS Windows resembles VMS so much is that the guy who was in charge of the project came from DEC. He wanted to create a "next generation" VMS, but the DEC board of directors weren't interested so he took his ideas to Microsoft, who were. As you can imagine, this ended up in court with MS having to open their wallet wide to compensate DEC in the end.
CP/M resembles TOPS-10 from DEC, because the developer was familiar with it. MS-DOS was in turn a deliberate 16 bit knock-off of CP/M created by one of Digital Research's (the owner of CP/M) source code licensees. This made porting application software from CP/M to MS-DOS was much easier. MS-DOS was successful because it was much cheaper than CP/M-86 or UCSD P-System (the other operating systems which IBM offered with their PCs), and IBM had lots of third application ports from CP/M lined up at launch.
The reason that MS Windows servers sold so well was that they were initially sold to the bottom end of the market at a time when businesses were looking to add basic file and print server networking capabilities to lots of small offices and to offices attached to factories and retail operations. MS Windows was comparatively cheap, and it worked on cheap commodity hardware. These businesses already had MS-DOS and MS-Windows 95/98 desktops, and Windows NT Servers worked with them more or less out of the box.
At the time your options in that market space were either Novell Netware or SCO, or to go with one of the big to medium size hardware/software package vendors such as IBM, DEC, HP, etc.
At the time, businesses were trying to break away from vendor lock-in. Users saw vendor lock-in as deriving from hardware, and didn't realise that proprietary software could present an even more difficult lock-in. MS Windows ran on commodity hardware and it was cheaper than the other proprietary software vendors. BSD was around at the time, but the developers weren't interested in running it on anything other than a "real" (e.g. mini-computer or unix workstation) computer.
Microsoft planned to inherit the market share which belonged to the proprietary hardware/software combo vendors by offering proprietary software on cheap third party commodity hardware. The hardware vendors would be squeezed by competition into accepting thin margins while Microsoft hoovered up all the profits into their own pockets. Hence, this is why they threw their toys out of the pram when Linux came along and spoiled that business plan by offering cheap commodity software on top of cheap commodity hardware.
"At the time your options in that market space were either Novell Netware or SCO, or to go with one of the big to medium size hardware/software package vendors such as IBM, DEC, HP, etc."
There were quite a number of small Unix systems about - including Xenix. Most were on 68k family proxessors but also Zilog Z8000s. My impression at the time was that IT managements regarded them as strange and mysterious. Of course those of us who'd taken a little time to familiarise ourselves found them to be very logical. My initial encounter with Windows - at a time, say about 1990, when 386s were not only new but rare was to run an X server to access HP-UX and Xenix. TCP/IP networking was also regarded as new and strange by the local management.
As an additional note on the clunky A:, B: and the like, I seem to recall that an intermediate version of MS-DOS (3.2, I think) had a built-in command, join, that enabled the user to do the rough equivalent of the Unix mount command, with the same beneficial result of being able to treat all the disk resources as a single directory tree. MS lost me when they removed it, and a number of other useful items, in the standard part of the next version and made it a $60 or so additional utilities package
I switched right then to Xenix, which I picked up used at an amateur radio swap meet, and never after paid more than the minimum necessary attention to MS operating systems. I did note that Windows hid the clunkiness rather effectively, and disks grew quite rapidly, so that for many it made little difference.
"Yes, that's the issue. People continue reinventing an outdated system - Linux is an example, instead of finally getting rid of it and design something for the XXI century onward."
The problem there is entrenched existing OS, vendor lock-in, comparability and the applications ecosystem.
Not to mention that no one seems to know what a modern XXIst century OS ought to be. Why would it be better? How would it be better? Why is "a 1970's based" OS so bad for the modern day? Most people creating new OSs today are building their own versions of the accepted OS designs already extant. A paradigm change (which is what you seem to be suggesting) is the sort of thing that comes from a genius visionary, not your average code hacker following the accepted teaching.
@Flocke Kroes - It is possible that there are architectural limitations to PowerShell which require building ssh in to do everything they want it to do. PowerShell sits in its own little PowerShell universe.
As an aside, I've been using the port of actual ssh server (but not with PowerShell) on MS Windows in a software testing environment, and have to say that for what I need it has been hands down the best solution I've found. Everything else either wouldn't install (Windows 10 desktop), or needed massive farting around try to configure the networking options to handle the fact that it was running in a VM. Ssh simply worked (or at least it did once I realised that MS's installation instructions were wrong).
I've been running MS Windows instances in VMs, and then using scp to upload source code and download test result files to and from the VM, and it's worked great. I hope they continue to maintain it.
I've asked this before - What, exactly, are they embracing in order to extinguish? They're not embracing, they're adding something, something which, by evidence here in this thread, is not going to be used by penguins who will cling to their bash with their puny little wings and clenched bills until the Planet dies in the ultimate heat death of the Universe. No embrace, a little bit of extending, and nothing to extinguish except the bits they added and they can't do that coz its now open source. So...?
The Embrace - Extend - Extinguish litany is becoming a lame pavlovian response from MS haters who have become so reactive by now that their knees begin jerking even before the word Microsoft has been assimilated in whatever it is they are reading.
Oh, I do so enjoy threads like this one on a dull day. Nothing more likely to make me smile than a fervid flock of penguins waddling after their arch enemy. More please :-P
It's pretty obvious to anyone who understands the GPL, that extinguishing of that nature is not possible. You think people are worried Linux will be bought out like Nokia?
People are perplexed at Microsofts recent 'Linux moves, still remembering the 'linux = cancer' line they pushing not long ago.
I've Win 10 on a VM, I'm interested in the bash subsystem, but why would I run bash on Windows on Linux (reminds me of that Father Ted episode, and the extension built on the extension).
Microsoft have embraced Unix tools into Windows 10 with the Bash subsystem, they are extending the influence of Windows infrastructure by providing them for Linux in the form of .net and Powersell, all the hopes of extinguishing a little more competition and getting more Azure sales.
You had to twist a little there to get the E/E/E concept to fit. Well done; you did it. I'm not convinced though that E/E/E isn't just a mnemonic for MS is Evil. Just sounds like normal economic business to me and there are other businesses that better deserve my ire than a software manufacturer. Mind you, I can spare a bit for MS - that whole privacy thing sucks somewhat, but watching everyone jump on every tiny little thing that they do...well, I find it entertaining. Sue me.
You had to twist a little there to get the E/E/E concept to fit.
- Hmm, just at the 'extinguish', I felt it was just a little tenuous, but the extinguish has always been about less competition (preferably none) = more Windows licence sales, so I think it's valid.
Yes, E/E/E has been used too much, as has M$ and all the other slurs, but they started with justification. Certainly normal business practice involves getting your product the in the best position, but I shouldn't have to remind anyone here that Microsoft are on record as having abused their position like a runner shoving competitors off the track.
They might be under less 'chair flinging' management today, but it's too soon to expect a total reversal in it's company mindset.
"The Embrace - Extend - Extinguish litany is becoming a lame pavlovian response from MS haters who have become so reactive by now..."
when the blind lead the blind, both go over a cliff, or so I've heard...
In this case, it's the "extend" portion of 'embrace, extend, extinguish' (like I mentioned above already). We know what their plans are, and if they CAN, they'll insert ALL of the worst things in Win-10-nic into Linux as well, so nobody will be able to go anywhere ELSE except a Micro-shaft controlled spyware-ridden and adware-ridden environment, in which THEY get "a piece of the action".
Again, I predict a WHOLESALE REJECTION of this powershell on anything but micro-shaft operating systems, MOSTLY because of ".Not" and all of the implications that go with it (and future embedded adware/spyware/tracking).
"do one thing, and do it well" indeed. That, 'powershell' is _NOT_ .
(a shell should be glue for the many 'do one thing' utilities, NOT a monolithic over-controlling piece of bloatware that tries to DO IT ALL, and does so POORLY)
Writer needs to find out what a shell is. Calling awk,grep, and sed shells is like calling print an OS. Article clearly written by a PR flack with little experience with admin. Also if it is open source where can I get the source code, without registering my email and personal info like at MS.
What the heck are you on about?
A. The only mention of awk and grep is from Snover in a direct quote, ie: it's what he said, not what we wrote.
B. He's saying you launch awk and grep from a shell.
Also, there's a link to the source code in the article - it's on GitHub.
Actually, if you have a task that warrants those features, you can definitely run awk, perl, and python (and no doubt several other such programs) as shells. I've certainly done so with awk and perl (python not so much because I'm old enough to remember the war against column 6).
Microsoft was doing open source back when I was a PFY. The license went something along the lines of "If you could have glimpsed Microsoft's source code, and you profit from software that does something similar, Microsoft can sue you to bankruptcy".
The article says "permissive MIT licence". The difference between that and a standard MIT license was not obvious with couple of quick web searches. Microsoft have been releasing software with MIT-like licenses for years. It is a big step up from their early poisoned chalices. The bit that is missing is the patent promise. Last time I looked, Microsoft promised not to sue you for patent infringement if you created a standards compliant implementation of the .NET framework. If you created an implementation that was compatible with theirs instead of being standards compliant, you had no such protection.
It has been years since I looked at Microsoft's terms and conditions. I could be very out of date. If Microsoft has made a stronger commitment not to sue developers, a link to it would be appreciated.
"Microsoft was doing open source back when I was a PFY. "
For a specific example, MS released ANSI C source for the compound file format used by OLE applications (such as the original Office apps) about 25 years ago. A number of FOSS packages use that source or something modelled on it for their own support of such things.
The Win3 SDKs also documented the WRITE document format and a couple of other applets as I recall. It was sufficient for me to produce .WRI files as an output option for a program back then. The WORD 6 and EXCEL file formats have also been open for a couple of decades.
These aren't *big* examples, but they are *old*. MS has never been 100% closed source.
Having had the misfortune of having had to work with PowerShell, I'd prefer their bash for Windows get prime slot, and PowerShell be taken out behind the shed and dealt with in much the same way as Old Yeller.
Really, it's just one of those hellish products that sounded like a really good idea until you saw how genuinely awful it was to work with.
could not agree more.
A few years back, MS issued a patch that had a side effect of stopping the MSCS cluster control plugin from working (Server 2008R2). WTF! Thankfully, they actually started to test it after it had been released (SOP then).
A week later we got an updated patch that rectified it. Won't get the 200+ man hours we expended trying to sort it out back though.
Thankfully, the customer learned a valuable lesson and didn't roll out Patch Tuesday releases the next day but now waits for at least a week.
Shame that us mere plebs (who can't legally buy enterprise edition) can't stop W10 patches from being rolled out and crapping all over your system.
Yes, clearly it's rubbish as a shell, but they've got tons of crud that runs on top of it.
So this is actually rational. Amazing as that is. This allows people to run MS stuff on top of a real operating system.
Well, there's not all that much logic to doing that either - but, if you've paid lots of money to buy licenses for the stuff, and your poor users are too set in their ways to change, now you can slip in a reliable OS, and all they'll notice is fewer problems.
Powershell is the worst. Text interfaces are supposed to be short commands. You have to type out powershell, just to open it instead of just PS. And from there it just gives German a run for it's money. The \. to access files breaks any conventions from DOS or *nix as they do opposite things. And the idea of breaking up nouns and verbs to simplify things has had the opposite effect. I can't wait for this to die. Thanks for putting a face with a thing that I hate. Does it come in dart boards?
I'll let you have that point, but my first impression of Powershell was that it looked like someone had decided to marry the readability of COBOL with the simplicity, elegance, portability and flexibility of DCL. ;)
Personally I found PS pretty awkward to use - but I've been mucking about with tcsh, ksh and bash for a couple of decades - so I am probably incapable of giving it a fair shake. I can accept that some folks like PS - fair play to them, but I don't understand *why* they like it !
PS is used to run stuff off command line.
There's an editor along with a shell CLI. You can autocomplete commands to avoid long typing.
It's a bit of a weird thing to get your head around at first, but when you do it's frighteningly powerful. The problem with it on linux is that to use it properly it will need .net framework in as it has full use of this.
Whereas BASH is so seductively alluring, wide eyed and open mouthed, with soft purring husky syntax, you've written 100 scripts without even being aware of touching a key. I just think what I want to do and its done! Magical! Almost Appleish in its beauty.
Every programming and scripting language in the entire multi verse has its awkwardnesses and gibberishnesses. We prefer that which we are most familiar with and have used the most. And also use that which we think makes us look cooler. Nothing MS does these days is cool, so must be rubbish.
"Now we have a cmdlet, New-Cronjob.” The cmdlet does error checking before accepting a new job."
Well better late than never I suppose.
I have no idea just how long webmin has been able to do this and a hell of a lot more as well.
Instead of "Windows on every desk." it looks like the new MS motto is "Me too."
The number of times I've seen someone trash crontab with crontab -e when something goes wrong with the session. Much safer to redirect crontab -l to a file, edit the file and then load it with crontab file. Also presents nice opportunity to version control crontab in production environment.
Linux folk love having a choice regarding doing just about anything and we can choose not to use Powershell.
That said, Microsoft would benefit from any 3rd party systems having powershell as a way of controlling them. If Linux can use powershell too then manufacturers of 3rd party systems e.g. VMware can argue that they do not need to add or support other methods of control and reporting.
It also means that Linux can work with Windows and other MS systems so removes perhaps part of a nail?
We will have to wait and see if this turns out to be the one of the last breaths for Microsoft as they make their death rattle sounds of irrelevance with regards to server infrastructure....
Okay, I can see advantages for some people here in the area of cross-platform use. And I know many of us have to deal with Windows at work, so this could be a valuable tool.
At the same time, I (and many others) have abandoned Windows due to the whole Win X debacle. I'm not much excited about MS extending their tentacles into the Linux world. I just don't trust them. Do you trust Satya? Does it really sound like a good idea to put anything from MS on your Linux machine?
Am I overly paranoid? Well, three years ago, when I was a happy, little Win 7 user, I never would have imagined that MS would go so completely over to the Dark Side and shaft their users as they have done with that deadly weapon known as Win X. How many others saw that one coming? I don't know what new nefarious schemes Satya & Company are working on, but, given that MS has clearly demonstrated complete arrogance and a total lack of concern for their users, I wouldn't be surprised by much of anything they did. I say beware!.
MS Jekyll - No more of this cancer stuff. Open source is good, openness rules. Let's go beyond Mono and open up .Net. You know, let's add bash to Windows. Let's be hip and cool. Let's support Linux on Azure. Let's use 8 and 10 to clean up a lot of underlying cruft in the old XP stack.
MS Hyde - Ribbon. Metro UI! We rulez and know best!
MS Jekyll - After Win 8, we need to be nicer. Let's upgrade our customers to Win 10 for free.
MS Hyde - Yummm! Telemetry. Yummm! All your data belongs to us. Forced Win 10 upgrades. We know best.
MS Jekyll - SQL Server on Linux!
MS Hyde - I know, let's send out an Anniversary Edition before QA is done on it. ME, AE, same difference. Let's pretend we use Telemetry to figure out our customer preferences. But then... aha, totally ignore whatever UI/behavior changes they request from us.
MS Jekyll - Powershell for everyone. Go talk to customers, meet your customers where they are. We’re confident that if we help our customers be successful we’re going to prosper.
MS Hyde -
... not there yet, but I am willing MS is more than able to bazooka its feet off several times in the near future.
Truly, I wonder how MS can be so bipolar these days??? How can it move on significant cultural changes, like accepting that it's got to play with others? And be even more bloody arrogant, and incompetent, than it ever was under Bill? Esp when "good MS" is mostly visible to geeks, but "bad MS" makes the front page news quite often these days.
There is the seed for a more mature, respectful company, but they insist on chucking it out.
The only mistake you've made there is in assuming there's only two sides to Microsoft's personality.
It sometimes looks like every single department of MS with more than three employees has it's own vision of where the company is going, with no idea of what the rest of the company are up to.
>Oh no! Open source code that's enterprise quality! I see why you're upset.
Is there any Redmond OS that is enterprise-worthy?
Oh, the other week I had the joy of installing Windows Sewer 2012, with AD and IIS .. updating to the latest patches ... The following issues were encountered:
1. Windows Sewer cannot find drivers, apparently, it does not accept Windows 7,8,10 drivers automatically ... you have to select a driver from the list of all drivers for all devices... go ahead, look up what Ethernet chipset I have to select the appropriate driver manually... That is even worse than the desktop version of Windows which, quite frankly, has Alzheimer with USB devices ! You know, devices like mice, keyboards, or headsets ... it searches autoMagically for hours for the driver - although the device in question has been plugged-in to the computer for the past 6 months ... How dare you reboot with it unplugged ? Now I have forgotten how it works!
2. The manage your sewer wizards are borked ... as in, you can have 5 wizards open, you have to think about which ones you start first, because it has consequences on the others - this is not always straight forward. Sometimes, they fail because some service has missing privileges, as in, the bloody wizard "recommends" you use network service for this or that, then later falls over because network service requires this or that priv ... which you have to go along and fix manually, restart the wizard.
3. Anything you do takes ... ages ... and I have a pretty nifty system, I can run SAP AS ABAP+JAVA on the bloody thing at "reasonable performance levels".
4. It has a tablet ui.
5. It requires a reboot for every second mouse click, almost.
6. Prior to installing the OS, please unplug any disks that setup will not be using ...
NB: This was a bare-metal installation on an SSD.
The wizards feel like 1999 Linux ncurses install scripts, where the devs had only implemented a third of the combinations you could select.
YOMV, but this is NOT what I call enterprise software ....
>"software problems will be fixed by our legal department, not by software developers".
In the history of IT, nobody has ever managed to squeeze a dime out of a software purveyor for poor quality code, crashing programs, servers or whatever ... ever! If that had been the case, a dime per crashing Windows server, for example, MS would be bankrupt, and that even if we started it today.
It wasn't ported. This is the actual PowerShell code, running on the CoreCLR implemented for Linux. It's exactly the same code they're doing development on in Windows, and it's done. If there's something that doesn't work, file an issue or fix it and submit a pull request.
As far as the security audits are concerned, that's expected. They want you to take a look and find anything and everything that's wrong, and either file an issue or submit a pull request.
Call them on it. Give it a try.
This will be a vital component to being able to host an on-prem Azure cloud on top of Linux-based hypervisors. Most admins probably will never use this, but it's a boon to Microsoft's developers and partners.
I supported Hyper-V at my last job and personally watched the cluster fail about 2-3 times per month, usually caused by running updates. Microsoft is finally starting to realize that they've lost control of their driver development, and it's becoming more dangerous to run Windows on bare metal. They're trying to stop selling hardware, period, so that way their driver team can focus solely on virtualization, and that means making Microsoft tools that play nice with the Linux hypervisors.
As there is no trust any more on the hidden telemetry and we know best on everything, there is no way on earth any Microsoft stuff is being installed on any of my Linux kit - ever !
After all my kit is working and stable, I don't want a wonderful new world of instability in my day.
>>I supported Hyper-V at my last job and personally watched the cluster fail about 2-3 times per month, usually caused by running updates.
I used to work on a very large Hyper-V cluster which used to have all sort of failures several times per week, usually caused by god knows what...
One of the worst experiences ever with a software product, even the Windows guys were left scarred.
Can I ask an honest question? How many of the Bash people who are on here bashing Powershell have actually used it? If you have used it and have genuine criticisms then fine. Share your issues with us, but if it is just reflex MS hating then you are doing yourself a disservice.
Contrary to some of the comments here, I can say that Windows has been manageable from the shell for years. I have been building and managing Windows environments for longer than I care to remember and mainly do it from the command line. Most times the built in commands have been enough. Sometimes I used add-ons such as Kix. I am not averse to the GUI either. It is useful for quick simple changes, but anything that needs doing multiple times or against a lot of objects gets scripted. Different tools for different tasks.
When Powershell first emerged in Exchange 2007, I didn't like it. It was new, it was wordy, it was different. Why do I need to learn something new? Then I started to use it more and began to realise how powerful it is.
The verb-noun structure is consistent and makes things readable, but if you find it too wordy you can alias any cmdlet or use tab completion. The real power is in the object pipeline. Every other shell I have used (Windows or Linux) usually requires that you parse the shit out of the output of one command before you can feed it into the next. With Powershell you just pipe the objects along the line. If you want pretty output you just pipe the final output to HTML, XML, whatever.
I still tend to revert to old shell commands to do stuff because I know them, but then I look at Powershell and realise that what previously took a 20 line script can be done with a Powershell one liner.
Take a look at it with an open mind. You might be surprised.
It seemed a Latte alternate to traditional use of .cmd files using all those lovely Admin utilites on the MSDN / Tech disks, for people that had never bothered to automate creation of 2,500 NT Domain user accounts automatically from the student admission database. I didn't use a Unix shell on Windows, though I had one since 1998, but couldn't see the point of Powershell for people that had actually learned how NT and all the 32 bit NT console utilities worked rather than pretending it was a DOS console.
NT3.1 came out in 1993. By 1995 some people were quite expert at Admin of NT3.5, how do you think people PROPERLY did NT Administration using script / console / automation before Powershell came out, TWELVE years later? Without Services for Unix either.
"Can I ask an honest question? How many of the Bash people who are on here bashing Powershell have actually used it?"
I am not a "Bash" person, but I use it daily... The shell + 'standard' UNIX utilities have ~40 years worth of effort & usage invested into them across all kinds of OSes and hardware ranging from -11's all the way up top 10 HPC clusters. They have proven themselves over and over again, Powershell has to appear to be a lot better than the incumbent to win folks over, Microsoft's entire business is built on this concept.
From my point of view (which doesn't count for a great deal in the scheme of things), Powershell just isn't better. I found it was actually *harder* to use - more verbose, a bit jarring on the eyeball and obviously a lot less familiar than my comfy awk slippers and sed pipe. I'm not saying Powershell is all wrong or fundamentally broken, it's just ugly, ungainly, weird and unattractive to my eyes. By the same token countless "MS People" asserted the UNIX "standard" utilities are also ugly, ungainly weird and unattractive to their eyes. It's the vi/emacs war all over again. :)
In the long run I think a bit of cross-pollination of ecosystems is usually a good thing and this is no exception. I won't be unhappy if Powershell unseats Bourne shell *if* it really is a better option, I just want to get the job done without having to make a drama out of it.
I used PowerShell in a past job, and had been using Linux for about 8 years prior to that. So please excuse the bias.
PowerShell rubbed me the wrong way because Microsoft can't document their way out of a paper bag, and so the learning curve is ridiculous. If you're going to write a whole new shell that bears little to no resemblance to existing shells, then you need to include comparisons to other shells in your documentation so that way the novices can get up to speed faster. You can't just assume that everyone that supports Windows environments is going to have some experience with PowerShell, because PowerShell isn't the default shell on the consumer versions of Windows. Bash, on the other hand, usually is the default, and on most Linux distributions you are practically forced to interact with it eventually to diagnose a problem or run updates.
The problem with PowerShell is that you're never forced to touch PowerShell until you get to college, or in some cases not even until you get a job. If you don't gently introduce these tools at an earlier age, you will always have a sizeable rift between novice and expert PowerShell users.
It does have the problem of being different and can be a steep learning curve. That is why I said in my original post I still default to "classic" shell tools. Almost everyone hates it at first.
However, I have lost track of the number of times I have seen colleagues who were hating on powershell when they first use it suddenly getting the lightbulb moment when they realise they can do something far more easily than they used to be able to just by filtering objects and shoving them down the pipeline.
All I can say is keep at, you might grow to love it (or at least not hate it quite so much).
The documentation is a lot better now. The verbose help or TechNet pages should answer any questions.
PS Powershell is included in consumer versions of windows. Every version of consumer Windows since Windows XP has been exactly the same codebase as the server edition (every NT version prior to XP as wel,l workstation and server were the same code). 32 bit XP was the aberration where they branched off the main NT codebase.
>>> When Powershell first emerged in Exchange 2007, I didn't like it. It was new, it was wordy, it was different. Why do I need to learn something new? Then I started to use it more and began to realise how powerful it is.
Are you for real? are you serious?
Of course powershell is da bomb in Windows, its fossil terminal and batch prior to powershell were utter crap.
"How many of the Bash people who are on here bashing Powershell have actually used it?"
I tried it once or twice under windows, and like the Eldritch Abomination that is ".Not", it's hellspawn 'powershell' is the hideous nightmare from the bowels of hell that it's portrayed to be by us "bashers".
When I decided to learn Linux and BSD, I had to start over with the shell. In the case of BSD, there are actually TWO shell syntaxes that are slightly different (csh vs sh/bash). I find that once I dove in, it was relatively easy to pick up and very very logical, and it helped me to learn Perl.
Powershell, on the other hand, is _SO_ tied into the ".Not" thing that I couldn't stomach it for more than a few minutes. It was like: no. no. NO. NO! NO NO NO! NO NO NO NO NO NO NO!!! I was like Saavedro in that pathetic 'No' scene towards the end of Myst: Exile.
".Not" was the cancer that really killed windows. It increased the slowness, tried to turn senior developers (used to WinAPI, MFC) into JUNIOR developers (by changing the game and all of the rules into bass-ackwards "object-oriented" nonsense that's really BLOATED and INEFFICIENT collection-based sewage). No thanks. re-learning "that" simply because it's *new* is not acceptable. On the other hand, learning bash after using CMD and command.com was kinda interesting.
FYI - I'd written a command line shell for Windows 3.x back in the day, extending the DOS commands and allowing you to run windows applications either synchronously OR asynchronously, with some rather nice extensions. There was also a REXX for windows, which my shell played nice with (by request, actually, I made those modifications). But of course Win '9x made it all MOOT with CMD playing nicer with windows applications and the 'start' command (not the same as the start button). But if I'd had cygwin back then, I would have used THAT instead.
There was also a REXX for windows
*Sniff* I also used to use REXX back in the days of nt3.5.1; Nice thing was that REXX also had a linux port at the time.
Just checked ... seems like the REXX interpreter is still there!
$ apt-cache search rexx
regina-rexx - Regina REXX interpreter
I have been building and managing Windows environments for longer than I care to remember and mainly do it from the command line
So many times in these forums (though not so much recently) I've seen MS shills/fans stating that "you need to do everything from the CLI" in Linux. It's nice to see someone admitting that even for Windows, CMD/PS is often easier and sometimes the only way to fix a problem or administer the system.
For that, have an upvote.
Depends on the task. User wants a group membership change or password reset, use a GUI. Standardised build of an environment or mass create of hundreds of user accounts, use a CLI.
Whichever tool achieves the best result in the quickest time, matched to the skillset of whoever is making the change. Far easier to give first line help desk GUI tools for a subset of tasks such as password resets.
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.
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.
Biting the hand that feeds IT © 1998–2019