????????
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.
https://www.youtube.com/watch?v=HOxeH_OQpFw
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.
This post has been deleted by its author
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.
you're welcome.
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....
Simples..
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.