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 322332
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[9]: cygwin
by BluenoseJake on Thu 10th Jul 2008 13:19 UTC 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

RE[11]: cygwin
by BluenoseJake on Fri 11th Jul 2008 00:17 in reply to "RE[10]: cygwin"
BluenoseJake Member since:
2005-08-11

"Stop listening to marketing guff and start looking at real world examples like the deprecation of Visual Basic 6 compatibility"

Yeah, seeing as VB ver 1 came out in 93, and VB stayed code compatible with that version until VB 7, 9 Years later, I'd say that argument is just nonsense, and I know, I started programming with VB 3. Standard BASIC code would run under VB, so it was even code compatible with GWBASIC and Quick BASIC.

Biggest change before .NET was VB 5 with OCX controls, but it still would use VBX controls until version 6, and it was still code compatible.

"the half-a dozen slightly incompatible versions of the Win32 API"

There are 3 versions, Win32s, that ran on Win 3.11, Win32 (Win9x) and Win32 (NT). 3 Versions, and only one is extant now. That certainly isn't a half dozen.

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

No. I am a Sys Admin, if I started thinking like a CTO, I would suck at my job.

Reply Parent Score: 2