Up until five or six years ago, all I ever heard from Windows fanboys was how great Windows was because it could be administered from a GUI, and there wasn't that stupid ugly primitive command line interface which only old men, BSD weirdos and Linux fanboys had any interest in using. Then, when Monad matured into Powershell, and became capable enough to at least replicate all the kludges and awfulness of VBScript and WMI, suddenly their note began to change. The first I saw of it was taking an online Server 2008 course by Microsoft, which announced that Windows Server 2008 was the most advanced server operating system ever, and bragging about how its advanced Powershell interface and scripting language put it to the head of the pack (I'm not kidding, this was actual an MS course). Then the Microsoft types started the "Powershell is better than silly old bash because OBJECTS!"
I'll readily concede that it is by far the best automation tool available on Windows to administer Windows. But that's really false praise, considering how bad the previous automation systems were (remember the evil old days of GUI "scripting" software), and really, while it may be perfectly suited to Windows, the idea that it's somehow some great quantum leap forward as compared to the *nix ecosystem is little more than just empty bragging by a contingent of cheerleaders who were, before Powershell came on the scene, were sneering at CLIs.
So really it is security theater, with a dose of security through obscurity.
At the end of the day, the only thing that actually protects any environment are the low-level permissions systems. Signing scripts is just a false sense of security at best, and a general pain in the ass otherwise.
The problem with all these solutions were the limitations to what you could actually manage. CMD.EXE's major innovation mainly surrounded the extended syntax and logic surrounding the FOR command. And yes, the scripting host did provide the ability to create WMI and COM objects, and I did a lot of scripting in VBScript to automate various tasks, but it had limits on what it could manage, and I remember a number of my scripts had to manipulate the registry.
Powershell, particularly in the last few iterations of Windows Server does have that benefit, that much of the system's functionality and most of its modules are scriptable, so on that score I do applaud MS. It's taken the better part of two decades, but they finally have a scripting system that can manage a Windows system with similar capabilities as *nix has had for decades. I just wish that solution wasn't an awkward language like Powershell.
If Joe Newbie doesn't have some level of Administrator privileges (in particular the domain and enterprise level admin group membership) these vile organization-crushing powershell scripts couldn't do it at all. Citing the possibility of an inexperienced admin is an issue, but is it the policy in your organization not to allow the running of Powershell scripts until they've proven themselves, and if that is the case, then how is that any different than not giving elevated (i.e. sudo) privileges to *nix IT staff until they've demonstrated some ability with it.
That's my point, really. *nix security doesn't work because only really experienced people use it. That wouldn't be security at all. It works because unless you're able to gain elevated permissions, you're pretty much screwed (with the caveat about exploits, which Windows has as well). In that case, if you just enable shell usage for all your staff, and if Joe Newbie writes a Powershell script that deletes all users in an Active Directory Organizational Unit, unless he's got modify or admin privileges for that OU, he's shit out of luck. And if you're worried about Powershell being the problem, and leave Powershell disabled, or only allow signed scripts to be run, well, Mr. Newbie, presuming he does have some level of management permissions over that OU, can still go into Active Directorys Users and Computers and delete the users via the GUI.
In other words, the whole disabled or signed only Powershell script system is really just security theater. It really does very little to secure a system.
No, I'm asking how is cutting off a path of a file (as an example of the kind of shortened output Powershell commands can produce) informative? And yes, I know it's fairly easy to overcome, but it just strikes me that this is the kind of GUI-centric thinking (this kind of output is straight out of a Listview object) that infects Powershell.
But, as we are constantly informed by Powershell advocates, Windows is object oriented, so bash won't work on Windows. And yet, apparently, text-oriented *nix will be administered by Powershell? Methinks maybe Windows object nature has been somewhat oversold to justify why Powershell ended up so different than the most used shell scripting language family ever developed.
I don't want the results filtered even on stdio to a command window. Yes I know they're not filtered if redirected to some other stream, but the fact that it filters it for the command prompt is absurd, and often renders the output useless unless you throw in the flag. How is "c:\somedir\someotherdir\importantf..." useful?
Security shouldn't be attached to the running of the scripts, but rather what it is that the scripts actually do. Since Windows has that level of protection out of the box, having to enable scripts just to run is little more than some rather silly security theater.
To run scripts with the ease that bash runs scripts, you have to actively activate this ability, otherwise Windows wants only signed scripts. So now, Powershell still isn't as natively supported as bash is in *nix.
Having administered Exchange from Exchange 97 to Exchange 2010, I can confirm that it's a pretty shaky system and can throw up some huge gotchas on occasion. It's also a bloated nightmare. I'm not sure if there's an upper limit to the resources that Exchange would gobble up.
And more to the point, I think you misread the example I used. The END PRODUCT was a fixed-record CSV file to be imported into an inventory system. The initial data was a pretty weird mainframe format distributed by CDROM way back in the day, which had fixed-length records, but variant field counts depending on the inventory item in question. You first had to parse each line to sort out how many fields were in the record, then process them to create a CSV file. CSV was used simply because the inventory software could natively import CSV.
And really, I don't recall ever using regular expressions to process field names in a CSV file. Do people produce CSV files like that? Seriously?
Except Cygwin is even more bloated and slow than Powershell. I did actually work a lot with it about ten years ago, to the point where I even got a radius daemon compiled, but it was arduous and Cygwin can be a bit flaky. But really, the biggest problem is that it's slow.
There's no easy way to get Powershell scripts to run in the task scheduler. At the end of my little quest, more than a few recommendations basically amounted to run it as "powershell.exe -File script.ps". Powershell still isn't really integrated into Windows, for goodness sake.
Ever heard of awk and sed? I've been doing complex manipulations of data using tools like this for most of my IT career. Christ, I used awk to transform weird variant field exports from a mainframe to CSV to be imported into an inventory system while the most complex shell language Microsoft offered was the MS-DOS 6 command.com.
Honestly I think some of the people bragging up Powershell never really used *nix at all, at least not in any sophisticated way.
What I particularly dislike is how it automatically filters output, and you have to use arguments or other applets to give you fuller output. It just strikes me as being the exact opposite of how any particular command or script should work.
And objects, big fucking deal. I've been using Bourne variants for a quarter of a century and never thought "Boy, I wish I had classes".
Overly verbose, syntactically complex, and most of all just astonishingly slow. I use it because there's no real alternative on Windows, but every time I have to code in PowerShell, I just think "So close to bash, but yet so far away." I cannot imagine anything that would compel me to use Powershell on a *nix system.
After using a Windows 10 mobile device (a tablet) for a few hours now, all I can say is holy shit, does Windows suck on touch devices. Christ almighty, even in "tablet" mode, it's just bloody awful. No wonder Microsoft's mobile plans are falling through, what a fucking disgrace. Even early versions of iOS and Android had a better user experience. Please Nokia, be done with Windows.
No, the next thing they'll want is the ability to compel people to hand over the password without even the nicety of a court giving them the nod.
I'm still not sure why such a law is required. In general judge has the power to compel evidence to be turned over, and refusal to do so can lead to a finding of contempt, which could, if the accused did not comply, could lead to rather serious sanctions. This smells more like a trojan horse.
Do you have any evidence that the climatological community has been "infiltrated by Communists?" For that matter, do you have any actual evidence that even environmental groups have been infiltrated by Communists?
No, they are not denied funding. It's just that there are so few actual denier climatologists out there in active research that they don't publish or actually do active research. The lack of skeptics in the research and peer review world is self-selecting. The guys like Spencer, who do have some expertise, are too busy being paid to shill for oil companies that they don't actually do real science any more.
Slashdot Mirror
Up until five or six years ago, all I ever heard from Windows fanboys was how great Windows was because it could be administered from a GUI, and there wasn't that stupid ugly primitive command line interface which only old men, BSD weirdos and Linux fanboys had any interest in using. Then, when Monad matured into Powershell, and became capable enough to at least replicate all the kludges and awfulness of VBScript and WMI, suddenly their note began to change. The first I saw of it was taking an online Server 2008 course by Microsoft, which announced that Windows Server 2008 was the most advanced server operating system ever, and bragging about how its advanced Powershell interface and scripting language put it to the head of the pack (I'm not kidding, this was actual an MS course). Then the Microsoft types started the "Powershell is better than silly old bash because OBJECTS!"
I'll readily concede that it is by far the best automation tool available on Windows to administer Windows. But that's really false praise, considering how bad the previous automation systems were (remember the evil old days of GUI "scripting" software), and really, while it may be perfectly suited to Windows, the idea that it's somehow some great quantum leap forward as compared to the *nix ecosystem is little more than just empty bragging by a contingent of cheerleaders who were, before Powershell came on the scene, were sneering at CLIs.
So really it is security theater, with a dose of security through obscurity.
At the end of the day, the only thing that actually protects any environment are the low-level permissions systems. Signing scripts is just a false sense of security at best, and a general pain in the ass otherwise.
Any day now, Windows Phone and Blackberry are gonna like totally rule the world!!!!
The problem with all these solutions were the limitations to what you could actually manage. CMD.EXE's major innovation mainly surrounded the extended syntax and logic surrounding the FOR command. And yes, the scripting host did provide the ability to create WMI and COM objects, and I did a lot of scripting in VBScript to automate various tasks, but it had limits on what it could manage, and I remember a number of my scripts had to manipulate the registry.
Powershell, particularly in the last few iterations of Windows Server does have that benefit, that much of the system's functionality and most of its modules are scriptable, so on that score I do applaud MS. It's taken the better part of two decades, but they finally have a scripting system that can manage a Windows system with similar capabilities as *nix has had for decades. I just wish that solution wasn't an awkward language like Powershell.
If Joe Newbie doesn't have some level of Administrator privileges (in particular the domain and enterprise level admin group membership) these vile organization-crushing powershell scripts couldn't do it at all. Citing the possibility of an inexperienced admin is an issue, but is it the policy in your organization not to allow the running of Powershell scripts until they've proven themselves, and if that is the case, then how is that any different than not giving elevated (i.e. sudo) privileges to *nix IT staff until they've demonstrated some ability with it.
That's my point, really. *nix security doesn't work because only really experienced people use it. That wouldn't be security at all. It works because unless you're able to gain elevated permissions, you're pretty much screwed (with the caveat about exploits, which Windows has as well). In that case, if you just enable shell usage for all your staff, and if Joe Newbie writes a Powershell script that deletes all users in an Active Directory Organizational Unit, unless he's got modify or admin privileges for that OU, he's shit out of luck. And if you're worried about Powershell being the problem, and leave Powershell disabled, or only allow signed scripts to be run, well, Mr. Newbie, presuming he does have some level of management permissions over that OU, can still go into Active Directorys Users and Computers and delete the users via the GUI.
In other words, the whole disabled or signed only Powershell script system is really just security theater. It really does very little to secure a system.
No, I'm asking how is cutting off a path of a file (as an example of the kind of shortened output Powershell commands can produce) informative? And yes, I know it's fairly easy to overcome, but it just strikes me that this is the kind of GUI-centric thinking (this kind of output is straight out of a Listview object) that infects Powershell.
But, as we are constantly informed by Powershell advocates, Windows is object oriented, so bash won't work on Windows. And yet, apparently, text-oriented *nix will be administered by Powershell? Methinks maybe Windows object nature has been somewhat oversold to justify why Powershell ended up so different than the most used shell scripting language family ever developed.
I don't want the results filtered even on stdio to a command window. Yes I know they're not filtered if redirected to some other stream, but the fact that it filters it for the command prompt is absurd, and often renders the output useless unless you throw in the flag. How is "c:\somedir\someotherdir\importantf..." useful?
Security shouldn't be attached to the running of the scripts, but rather what it is that the scripts actually do. Since Windows has that level of protection out of the box, having to enable scripts just to run is little more than some rather silly security theater.
Yes, on Internet Explorer.
To run scripts with the ease that bash runs scripts, you have to actively activate this ability, otherwise Windows wants only signed scripts. So now, Powershell still isn't as natively supported as bash is in *nix.
Having administered Exchange from Exchange 97 to Exchange 2010, I can confirm that it's a pretty shaky system and can throw up some huge gotchas on occasion. It's also a bloated nightmare. I'm not sure if there's an upper limit to the resources that Exchange would gobble up.
And more to the point, I think you misread the example I used. The END PRODUCT was a fixed-record CSV file to be imported into an inventory system. The initial data was a pretty weird mainframe format distributed by CDROM way back in the day, which had fixed-length records, but variant field counts depending on the inventory item in question. You first had to parse each line to sort out how many fields were in the record, then process them to create a CSV file. CSV was used simply because the inventory software could natively import CSV.
And really, I don't recall ever using regular expressions to process field names in a CSV file. Do people produce CSV files like that? Seriously?
Why would I need regex for that in something like awk?
Except Cygwin is even more bloated and slow than Powershell. I did actually work a lot with it about ten years ago, to the point where I even got a radius daemon compiled, but it was arduous and Cygwin can be a bit flaky. But really, the biggest problem is that it's slow.
There's no easy way to get Powershell scripts to run in the task scheduler. At the end of my little quest, more than a few recommendations basically amounted to run it as "powershell.exe -File script.ps". Powershell still isn't really integrated into Windows, for goodness sake.
Ever heard of #!/bin/sh ...
You've been able to create sh scripts for decades, if you wanted to construct specific reusable scripts that invoked the toolkit in some specific way.
Ever heard of awk and sed? I've been doing complex manipulations of data using tools like this for most of my IT career. Christ, I used awk to transform weird variant field exports from a mainframe to CSV to be imported into an inventory system while the most complex shell language Microsoft offered was the MS-DOS 6 command.com.
Honestly I think some of the people bragging up Powershell never really used *nix at all, at least not in any sophisticated way.
What I particularly dislike is how it automatically filters output, and you have to use arguments or other applets to give you fuller output. It just strikes me as being the exact opposite of how any particular command or script should work.
And objects, big fucking deal. I've been using Bourne variants for a quarter of a century and never thought "Boy, I wish I had classes".
Overly verbose, syntactically complex, and most of all just astonishingly slow. I use it because there's no real alternative on Windows, but every time I have to code in PowerShell, I just think "So close to bash, but yet so far away." I cannot imagine anything that would compel me to use Powershell on a *nix system.
Not only that, but so the fuck what? Wow! Google Play for Chrome, which has about as much to do with Oracle as running Netflix on Chrome.
After using a Windows 10 mobile device (a tablet) for a few hours now, all I can say is holy shit, does Windows suck on touch devices. Christ almighty, even in "tablet" mode, it's just bloody awful. No wonder Microsoft's mobile plans are falling through, what a fucking disgrace. Even early versions of iOS and Android had a better user experience. Please Nokia, be done with Windows.
No, the next thing they'll want is the ability to compel people to hand over the password without even the nicety of a court giving them the nod.
I'm still not sure why such a law is required. In general judge has the power to compel evidence to be turned over, and refusal to do so can lead to a finding of contempt, which could, if the accused did not comply, could lead to rather serious sanctions. This smells more like a trojan horse.
Do you have any evidence that the climatological community has been "infiltrated by Communists?" For that matter, do you have any actual evidence that even environmental groups have been infiltrated by Communists?
No, they are not denied funding. It's just that there are so few actual denier climatologists out there in active research that they don't publish or actually do active research. The lack of skeptics in the research and peer review world is self-selecting. The guys like Spencer, who do have some expertise, are too busy being paid to shill for oil companies that they don't actually do real science any more.