Linked by Adam S on Tue 8th Jul 2008 12:47 UTC
Talk, Rumors, X Versus Y In 2006, Microsoft released Windows Powershell, a new command line shell that, via cmdlets, scripts, and executables, allow core system administration tasks to be scripted. While this functionality has been available on Unix-type systems for decades, Microsoft's version will almost certainly, within a few years, be available on several hundred million PCs. So how does the Powershell stack up against Linux favorite bash? MSDN links to this Bash vs Powershell article.
Thread beginning with comment 322196
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: cygwin
by StaubSaugerNZ on Wed 9th Jul 2008 20:05 UTC in reply to "RE[7]: cygwin"
StaubSaugerNZ
Member since:
2007-07-13

We are not a small institution.


Point noted - but your institution is still a relative minnow. You mentioned that your university has a mixture of environments. Why create artificial silos when you don't have to? Find common tools that will break down the barriers to make everyone's life easier, not only your own. It is a common failing of sysadmins (and computer scientists in general) to make life more complicated than it needs to be for the sake of a few shiny features. Microsoft believe that adding new features at the expense of dividing the market will work for them in the long term. They are wrong.

Be warned now that your scripts will probably break when newer version of Windows comes out (usually subtly). It is an unfortunate consequence of Microsoft's business model. At least it will keep you in employment as you spend your life maintaining your PowerShell scripts. Meanwhile, *sh* compatible scripts will keep working for the next few decades and we'll get one with doing more productive things.

Reply Parent Score: 1

RE[9]: cygwin
by BluenoseJake on Thu 10th Jul 2008 13:19 in reply to "RE[8]: cygwin"
BluenoseJake Member since:
2005-08-11

"Point noted - but your institution is still a relative minnow. You mentioned that your university has a mixture of environments. Why create artificial silos when you don't have to?"

There are no isolated silos here, there are much better tools available than scripting if we need systems to communicate. The systems we deploy have specific functions to perform, scripting shouldn't really be used as an integration tool between disparate OSs. That's what RPC/SOAP/ODBC/SSH/SAMBA is for.

There are better tools for the job. We use scripting to do specific chores on each server, or to facilitate moving data from system to system, why build the intricate interlocking scripts between servers, those are the scripts that will break, as servers change, business needs change, and if you have all these interlocking scripts, it makes migration and management a nightmare. Native scripting on each OS gives you much better access to the underlying functionality of the OS.

On top of it, the toolset on *nix is radically different than on Windows, and I don't like spending my time trying to make up for the differences in syntax between the native Linux version of grep and some Windows port. The Powershell gives me access to the entire power of the .NET framework, and that allows me to manage and automate things better on the Windows side. On Unix, a good bash script can't be beat, but a sh compatible environment on Windows needs a lot of extra baggage to be useful, baggage that just is not needed. It's all ready all there, exposed to powershell. Why reinvent the wheel?

"Be warned now that your scripts will probably break when newer version of Windows comes out (usually subtly). It is an unfortunate consequence of Microsoft's business model."

Uh, MS LOVES compatibility, I disagree with your statement 100%. I predict the powershell to be backwards compatible for quite a while. I would think that using scripts the way you describe would be a quicker route to breakage, as you have to 3rd party scripting environments, plus toolsets on the Windows servers. upgrade one, upgrade them all.

Reply Parent Score: 2

RE[10]: cygwin
by StaubSaugerNZ on Thu 10th Jul 2008 19:15 in reply to "RE[9]: cygwin"
StaubSaugerNZ Member since:
2007-07-13

Why reinvent the wheel?


Indeed. These are your words.

Uh, MS LOVES compatibility, I disagree with your statement 100%.


Stop listening to marketing guff and start looking at real world examples like the deprecation of Visual Basic 6 compatibility, the half-a dozen slightly incompatible versions of the Win32 API, inability of Office to read older documents perfectly etc. Then you see for all of the claims, MS does a good but hardly perfect job (they couldn't be perfect, it is against their business model since they need slight incompatibility to drive upgrades).

In fact, stop thinking like a sysadmin and start thing like a CTO.

Reply Parent Score: 1