Microsofts assistance to Moonlight is actually increasing.
Microsoft helped Moonlight users get legal access to commercially licensed codecs by allowing Moonlight users to download the codecs from Microsoft's site. That way the codecs are covered by Microsofts licenses (Microsoft licences these codes from 3rd party IP companies).
Perhaps more importantly Microsoft also open sourced the control widgets for Silverlight so that the exact same controls can be used in Moonlight.
That said, Moonlight still have some distance to cover to reach SL parity. I believe they are still missing code access security (CAS). CAS is paramount when you let foreign code into your system. It forms part of the sandbox which constrain what the foreign code can do (it has to declare up front was privileges it must be granted, and during execution it cannot go beyond those privileges). I believe that is the most important missing piece.
Silverlight 3 also features hardware 3D acceleration. I don't know how far Moonlight has come there. The other parts such as C# 4 and DLR Mono and Moonlight actually seems to be not to far behind.
But another area where Moonlight may actually be more compelling than Silverlight is in the area of cross-compilation. If not already, you will soon be able to develop iPhone apps in silverlight and cross-compile them for iPhone. As Apple does not allow any VM technology into their precious iPhone garden, this is quite interesting (by being compiled to native code Moonlight circumvent this restriction). Developers can develop games in Silverlight and can use almost the exact same code base for iPhone, Windows, OSX and Linux.
Also, do remember that Microsoft develops and supports Silverlight on Intel OSX too. At present Silverlight then covers some 97% of the market (Windows + Intel Macs).
I think he was referring to "isolated storage". Basically you can allow "applicatoions" to store data locally on your machine. By default only a limited quota is granted (the application can ask for more and the user has to approve it).
The stored data is obfuscated to avoid malicious apps downloading files/scripts and then use social engineering techniques to fool the user into launching them. This allows an app access to data even when offline.
Silverlight itself executes inside a pretty restricted sandbox. Silverlight has an impeccable security record Secunia reports zero vulnerabilities in both SL1 and SL2. That is not to say that there are no vulns in SL. But at least compared to Flash it's quite good.
Even so, installing yet another plugin/app will *never* make your computer *more* secure, except when you're installing some lock-down app or firewall. Obviously any app only increases the attack surface.
Even UAC is a bizarre hack of a permissive userland, and doesn't use the kernel's security features.
If you can get past the idea that UAC is only the UAC prompt you will see that UAC is indeed much more, and that UAC very much so use the kernel's security features.
Among other things, UAC manipulates the security token of the process, stripping away access rights. This is what is used for both the sandboxing of low integrity processes as well as the elevation prompt.
Normal processes launched by the user is stripped of admin rights by default. Only if the user is actually an admin and only when he tries to access something which requires those rights will the prompt appear. Confirming the UAC elevation prompt will grant the access rights to the process token.
Certain processes - such as Google Chrome and Internet Explorer - are launched in low integrity mode. The process token is stripped of even more rights, preventing it from writing to the registry or to the file system except for an isolated region.
The kernel also ensures that a lower integrity process cannot send messages (or otherwise access) a higher integrity process. So while applications you start on the desktop may send messages to eachother, the IE or Chrome instances cannot send similar messages to desktop apps, even if taken over by an attacker.
Essentially Vista/7 subdivides the user's account based on what he/she is doing. Surfing the internet: low integrity. Running normal, local applications: Normal integrity. Performing admin tasks: Elevated integrity. Installing new applications: Trusted installer integrity.
I have a Dell XPS notebook with built-in 3G card. I also run it on wireless and even connect the ethernet port from time to time. I use the 3G modem when I'm in a train to/from work, waiting at the station, attending meetings, conferences or when I'm on vacation. Of course the data plan costs extra, but being able to connect at all times is really, really convenient. I can even share out the internet connection effectively letting my notebook act as an access point.
Summary makes it sound like this is exclusive or that there isn't a market for it. Of course there is. Having broadband/fiber connectivity in your home does not mean that don't need on-the-road connectivity as well.
Right, and how about something to back up the claim that it *does* slow Windows down? That was the first assertion, so the burden of proof is on the first poster.
So how about it? Are you going to quote that "researcher" Peter Gutmann?
You've been had. The Vista DRM debacle was nothing but a smear campaign. Try reading someone who actually researched the topic as opposed to someone who just went with what he could find of anecdotes on random blogs. Ed Bott has made a series of well-investigated rebuffs of Peter Gutmanns diatribe:
Read "Everything you've read about Vista DRM is wrong (3 parts"):
Yes, Vista does have DRM. Otherwise it would not be able to play back DRM'ed media. An OS/App which doesn't support DRM cannot decrypt DRM'ed media.
Yes, decryption does take a few clockcycles. On XP, Vista, OSX or Linux. It would do so on any device playing back encrypted media. No way around that, except don't play DRM'ed media.
No, Vista DRM is not active when playing back non-DRM'ed media.
No, Vista does not cripple non DRM'ed media.
Yes, Vista does support the "protected media path" as *any* device which are licensed to play back hdmi are required to.
No, protected media path is not active unless requested by the media, which is very uncommon at this time.
For what it's worth, I don't believe that interoperability with OpenOffice was ever on Microsofts agenda. The political climate (skillfully navigated by Sun/IBM) dictates that an office suite in more and more states and public institutions must be able to check the "ODF compliant" box.
The problem is that ODF was pitted as a standard which would guarantee interoperability for office documents. It was also sold pitted as a standard which would guarantee that document fidelity across different, competing implementations and across different versions.
Those were good promises. I think it has taken a lot of people by surprise (myself included) that
1) the standard is clearly not yet complete enough to guarantee these goals
2) the primary implementation - from which the format is derived - is not in compliance and indeed writes application specific extensions into the documents which directly affects the fidelity of the documents (i.e. it will *not* print the same on a different implementation.
No, you may wish for Microsoft to aim for OpenOffice interoperability. But they really only need to check a box to satisfy legislators. That the box isn't big enough is a failure of the standard.
No, we're faulting them for following the specs to the letter and at the same time going out of their way to make sure their technically compliant implementation still doesn't work with all the other, existing implementations.
So, a standard was proposed and decided upon. It was then used to criticize Microsoft Office and used as an argument to urge government and public institutions to drop MS Office and use ODF compliant software. The argument was that
1) only a standard would ensure a durable document fidelity - i.e. that the document also in the future would be interpreted the same.
2) only a standard could guarantee interoperability.
Only, the ODF standard obviously failed in both of those aspects. And now the battle cry is that Microsoft should follow a draft, non-official standard or even a specific implementation because it will probably be standardized? gee, is it any wonder Microsoft had trouble succumbing to those terms? "Just write the dotted line, we'll fill in the rest later, don't you worry". Sorry, but ODF was (and is) still driven by Sun/IBM and it would be naive not to think that they wouldn't use that against Microsoft.
What is wrong about asking OpenOffice to follow the specs?
ODF does, for the most part, follow the specs.
For the most part. For the most part??? Have you any idea what would be lopped in Microsofts direction if they claimed ODF compliance and followed the standard for the most part??. I call hypocrisy.
The problems between OpenOffice and MSOffice's implementations are that ODF implements a newer version of the spec and MS hasn't caught up to that
Oh, please! At least be honest! You want Microsoft to adhere to an yet undecided, still draft spec. A spec which incidently has show remarkably little progress. The draft spec defines the structure for a formula language, but the actual formulas are still just "whatever is in OpenOffice". Wasn't that exactly the argument against the OOXML spec where some of the renderings specs in the early drafts were defines as "whatever Office 97 does". Sounds suspiciously alike. Fortunately those definitions were eradicated and replaces with proper definitions during the OOXML standardization process.
MS may, technically, be minimally compliant with the spec, but it is clear they went out of their way to be as minimally compliant as possible to make their version as incompatible and unfriendly as they could manage while still being within the spec.
It is not clear at all that they went out of their way. That's pure speculation. But that is really not the issue here. The idea behind the ODF standard was not to make everyone compliant with whatever OpenOffice does, but to make all implementations compliant with the standard. I suspect that Microsoft may smile in secret at this jab against Sun/IBM, but really, strict ODF compliance is their end goal because that is what can make or break contracts with governments and public institutions. It's just a box to check. Interoperability with OOo was never (I believe) their goal. The standard should make sure of that. OOXML does.
Yeah, but it was an attempt to level the playing field and let products win based upon merits instead of criminal leveraging of monopolies. I don't understand why people have such a hard time understanding antitrust laws and how they work and why we have them.
Oh, but that is perhaps the most positive outcome of all of this. It finally forced Microsoft to make their file formats public, to dispose of IP protections on the office format and to commit to an open standard and to continue to do so. I feel that was a tremendously positive result, and I'm deeply grateful to Sun, IBM and OpenOffice for forcing this upon Microsoft. At the time of the great debackle there were so much FUD in th
I'd say that it had a bad smell of Hypocrisy. If the standard doesn't cover important(I dare say) areas such as the friggin formula language, what good is the standard?
No, the author is trying to preempt the obvious and very valid argument that if the standard didn't cover this and implementers need to reverse engineer a specific implementation (OpenOffice), maybe the standard wasn't good enough?
The author is making silly analogies with someone willfully going through hoops (investing time) to sabotage interoperability with an implementation in which the implementor has chosen not to invest time and effort reverse engineering and testing functionality which is clearly outside the specification.
So now you're saying that the language for formulas should be defined by an implementation as opposed to being defined in the standard?
So, what happens when Microsoft comes up with a new formula and starts generating documents with that formula in it? Will other implementations be required to understand that as well?
Maybe, just maybe, there was a reason for OOXML to be longer than ODF. Maybe it is because it is more complete on issues such as this? But everybody were caught up ridiculing OOXML and arguing against competing standards.
IIRC the ISO committee hinted that there were several precedents of competing standards, and that the better (i.e. more complete one) would eventually become the primary standard.
What good is a standard if we still have to reverse engineer applications to achieve interoperability?
There is a problem with ODF being incomplete in several areas. Yet we hear ridicule over how the OOXML spec is 6000+ pages and ODF a mere 2000?
There are multiple problems with OpenOffice ODF compliance (inherited by derived suites). Yet, this is somehow a Microsoft problem?
One the one hand we require Microsoft to follow specs to the letter, and now we somehow fault them for doing so?
What is wrong about asking OpenOffice to follow the specs? How about ODF getting an ovarhaul to weed out ambiguities and to properly
What goes around comes around. ODF was initially just a clever assault launched by Sun and IBM. With one strike they propelled ISO into relevance and took Microsoft completely off-guard. But customers saw the light and started demand good standards. Only, it is now evident that ODF and the posterchild OpenOffice were never prepared for the success.
OpenOffice and derivatives, Sun and IBM just have to eat their own dogfood. Admit that the "perfect" ODF was at least partly a hype.
We've seen from the browsers what "lenient" parsing can lead to. It is called tag soup. Requiring all products to leniently compensate for ambiguities in the spec or faulty implementations are definately the wrong path!
The chickens are coming home to roost. Suck it up. Fix it instead of point fingers.
Tap the Alt key or press-and-hold it. Small letter shortcuts will show up next to all of the functions on the ribbon. Having learned the shortcuts simply press and hold the alt key (or tap it again) and key in the shortcut sequence next time.
To all those who don't get it, go look up "time unpatched" for each of IE's vulnerabilities. That is, time from when they were reported to time when they were patched. That's the time Microsoft left you swinging in the wind.
Not exactly. They actually left you "swinging in the wind" since they introduced the vulnerability which would often be since the product release. And that goes for any vendor, Microsoft, Apple, Mozilla, Ubuntu/Linus etc.
If a vulnerability is responsibly reported, the days following the discovery are no more risky than the days preceding it. Naturally each day counts, but there are also other concerns.
We just saw Firefox 3.0.9 introduced a new vulnerability which had to be patched immediately. That's not a desirable situation. For an enterprise a patch gone wrong can be far worse than being exposed to a responsibly disclosed vulnerability. We want to be exposed to vulnerabilities as little as possible (fewer vulns, shorter period), but we also don't want patches destabilizing our infrastructure.
Basically it is a judgment call. And unfortunately not one you can solicit opinions from the public/customers as that would defeat the purpose and forgo the decision.
BTW, even Linus Torvalds will not disclose every vulnerability. He has publicly stated that if he sees a vuln he will just fix it, and that he sees no need to jump through hoops to tell anyone about it. (a MO which may lead to the undesirable situation of bad guys being tipped of by diff'ing the source tree and figuring out the vuln before the fixes makes it through the various distributions).
Indeed, different OSes comes prepackaged with vastly different extra software. Especially many Linux distros comes with OpenOffice, Gimp, etc.
Although they haven't spelled it out literally, the methodology IBM used in their analysis was to compare the "core" operating systems. As an example they used "Linux kernel" and not a distro with any extra software. That way no office suites, browsers, media players etc. were considered. Just the bare bones operating systems with basic services. I suspect that in the case of Linux and other *nixes this doesn't even include the desktop manager whereas for Windows and OS X the stats will include any vulnerabilities from the GUIs.
You have to read these with caution, though. Microsoft has been trying to get the vulnerability count down, and one way of doing this is merging several vulnerabilities into one. It looks good on paper, but it does not make the product any more secure.
Perhaps you would look with caution, too? You are talking about advisories or bulletins. They are often aggregated. However, secunia lists a count for actual vulnerabilities. And those were the numbers I quoted.
And even in Microsofts own bulletins (not the advance notices) the individual vulnerabilities are clearly listed and identified with CVE references. CVEs are not aggregated, not from Microsoft and not from anyone else.
That being said, the recent product certainly show improvements. They absolutely beat Java and Acrobat, when it comes to security. I think the comparison with Firefox may be uneven, though, because the Firefox guys class just about anything as a potential security issue, just to be on the safe side.
So does Microsoft. An uncontrolled browser crash is a potential vuln. But you're right, if the bug is handled in a controlled fashion (i.e. caught exception) it is probably not classified as a vuln but rather a bug. I am not aware that Mozilla would do it any other way.
I haven't tallied by the the severities of the vulnerabilities. Theoretically all of the FF vulns could be "less critical" whereas all of the IE ones could be "highly critical". But I doubt it. Anyway, it's food for thought. I don't think we should give Microsoft nor Mozilla free passes.
You haven't been paying attention to the way Microsoft works, have you? This has been typical for.... ummm.... as far as I can remember. Ship first, patch later and frequently.
Erm. Then you haven't been paying attention to the way Microsoft have worked for the past 5-6 years, have you? They have seriously pulled themselves together since the code red, nimda and initial IE6 days. I know that it's a popular myth that Microsoft software is swiss cheese, but security analysts are starting to point at Microsoft SDL (Secure Development Lifecycle) as an example on how to do it.
Independent analysts, i.e. IBM, researching vulnerability reports, have for the past 3 years pointed out how Windows XP and Windows Vista are actually the operating systems hit with the fewest vulnerabilities (but still most exploits).
Looking at vulnerability stats at secunia shows that Microsoft QC have improved drastically across their entire product portfolio:
IE7 was released at roughly the same time as FF2. IE7 has had half (77) of the vulnerabilities of FF2 (154). And those vulnerabilities stopped counting last year when FF2 was EOLed. And FF3 is already at 68 - about to overtake the 3 year old IE7. Of course there are still browsers out there with much fewer vulns than all of these.
The.NET Framework 2.0 is roughly as old as JRE 1.5, and although the former also has "enterprise" stacks such as ASP.NET etc, the.NET Framework 2.x has been hit by 10 vulns whereas JRE 1.5 has had 111 vulns in the same period.
IIS6 was released with Windows Server 2003. Since then it has had 4 (four) vulnerabilities. IIS7 was released with Vista/Server 2008. It has experienced 1 (one!) less critical vulnerability. In comparison Apache 2.x has experienced 23 vulnerabilities. Considering what they had to work with, I'd say that's pretty impressive.
Silverlight 1 and 2 both have clean sheets. Zero vulnerabilities so far. Compared to Flash Player 9&10 with 37 and 5 vulnerabilities respectively , Microsoft is certainly doing allright there as well. Especially considering that some of those Flash vulns were high-profile potent vulns which were featured in pwn2own.
On the database front, SQL Server 2005 has registered 10 vulnerabilities. Oracle Database 10.x comes in with a staggering 828 vulnerabilities.
On the whole Microsoft seems to do pretty well and considerably better than their competitors in all of the above areas. And no, Microsoft does not hide vulnerabilities. They may delay publication in a responsible disclosure, but any MS admin will tell you that they are very specific about each vuln in their patch bulletins. Microsoft cannot slip a "fix" through, as they have to provide enough information for admins to take a decision whether to block or allow a given patch based on security against stability (like in fewer changes).
And Microsoft does not patch "frequently". They patch 12 times a year + emergency patches. This schedule has in general been well received by admins and several other vendors are now following the same schedule.
Nah, powershell exposes a unified object model. Although powershell itself is actually written using.NET it wraps.NET classes, COM classes and WMI classes in it own dynamic-aware classes. So, in a sense the powershell object model is a new object model on top of the others. It just happens to be coded in.NET.
While the term "kernel objects" is not very accurate, between Win32/COM,.NET and WMI, Windows nevertheless exposes most functionality of the operating system in an object oriented fashion. I think that is what GP was alluding to.
This is in contrast to both Linux and OSX which use text based pipes (although from a pure programming perspective OSX can be used OO) and it is also the reason why it makes a helluva lot of sense for PowerShell to use object pipes instead of plain text pipes.
There are actually a number of advantages to using objects:
1) they can be "live" meaning that if you pipe a FileInfo object to another tool that tool can directly invoke methods for deleting, appending, renaming etc. Likewise a piped ProcessInfo object (the result of a ps command) will allow any cmdlet along the pipeline to invoke methods to e.g. retrieve extra information, enumerate threads, change priorities, kill and whatnot.
2) results from tools need to be funneled through a narrow text based pipeline. Information "expensive" to retrieve (like enumerating threads and/or handles of a process) need not be retrieved by the initial ps command. If any tool along the pipeline need that information it will be retrieved when the "getter" is called (lazy evaluation).
3) no stupid errors because all information must be serialized to a delimited text format. File names, process names etc. can actually contain spaces without breaking parsing tools. No culture dependent parsing. Objects can readily contain properties of DateTime or TimeSpan types which can be reliably sorted and compared.
4) same advantages as using OO programming languages: the objects readily exposes (you can query for members) which member properties and methods they support. This means that actions can work in a object-action syntax rather than the usual action-object. It also means that methods (the actions) can be overloaded and result in a more consistent view of the systems objects.
5) objects contains metadata and are queryable. Instead of an "id" for a process - which looks just like any other integer number you work with the actual wrapper abstraction for the process. In the case of the id you have no further information as to what it denotes. With the object such information is readily available.
..., and is one of the early web applications to actually use something like AJAX to give you the feeling of using a desktop application.
More aptly, is was THE first AJAX application. It doesn't get earlier than that.
This was years before it got its spiffy name. XmlHttpRequest (the linchpin in AJAX) was invented by Microsofts email client team to support Outlook Web Access. Being invented for IE it was (and still is AFAIK) a COM object which could be created from JavaScript in the browser. Mozilla later copied the idea and made XmlHttpRequest a first class citizen, but kept the name. The rest is history.
While I agree with most of your points, I have to take issue with no. 7:
7) This is linux and not windows. Bash is much more powerful than the pitiful shell windows provides.
It's rather newish (2006) but IMO PowerShell generally blows bash and all other Unix shells out of the water. Arguably, PowerShell is much better for Windows, as more APIs in Windows are object-oriented and thus fit better with PowerShell.
Take a look at my sig. It's a one-line, slashdot sig fitting (OP has a point: If you are handling files with spaces in them, *many* scripts will break down due to the fact that *nix shells pipes are text-only and that many tools by default parse using whitespace as delimiters. In a shell with object-oriented or structured pipes this will not happen.
Sorry for chiming in, but it is kinda my pet topic at the moment.
If you can execute in the applications context, I think you can write to the preferences files - even if the app is in a sandbox.
No, not in a sandbox. That\s the difference between something like SELinux and a real sandbox. With SELinux you will be allowed to do what you legitimately need to be able to do. In a sandbox you will have to ask the broker process to perform the privileged operations. Neither Chrome nor IE let the rendering process access the local file system. Instead they supply a broker/helper process. Typically this process will interact with the user, i.e. if downloading a file it will display a dialog or visual element to let the user choose if/where to download the file to.
You are right that if you protect Firefox with SELinux, it still needs to be able to access the preferences store. Thus a contaminated instance will be allowed to do the same, i.e. it will be able to change settings without user interaction or consent.
Chrome actually takes it one step further, isolating each tab in its own process. This (in theory) prevents cross-contamination between tabs. If an attacker successfully compromises one tab he can still not intercept communications from/to the other tabs. While IE has a sandbox it doesn't protect individual tabs, merely the browser itself and the file system.
Per the contest rules it wasn't necessary to break out of the sandbox, so at this point it is not clear that that happened. Simply executing code in context of the application (browser) would be enough. You can still do a lot of damage inside the browser, i.e. install password/certificate snooping, monitor and inject traffic etc. But it all ends with the browser session. You cannot read/write users' files much less compromise the machine.
Unlike Firefox, Opera and Safari, Chrome and IE actually has such a sandbox. Chrome actually has a 2-level sandbox and a process-per-tab while IE only has a single sandboxed process common to all tabs.
In addition to that IE has a really big supply of extra defenses such as heap encryption, various stack overflow protections, mechanisms designed to foil exception handler exploitation etc. At least some of these must have been broken in the attack against IE8. Recently a couple of security researchers demonstrated how most (if not all) of these mitigation mechanisms (except for sandbox) could be broken by leveraging perfectly valid code to reduce entropy (most of these mitigation mechanisms work by introducing entropy or encryption thus lowering the chance of a successful attack)
Firefox, Opera and Safari has no sandbox and practically no extra mitigation mechanisms to speak of, except for those offered by the operating system. Again, OSX is a the bottom of the heap here, with practically NO extra mitigation techniques. Vista offers the most, especially on 64bit.
For the last couple of years, Firefox (not IE) has been the browser with the most vulns. Combine that with the fact that it has no sandbox, no extra mitigation techniques and that it relies heavily on extensions and plugins the quality of which cannot be controlled by Mozilla. That's a recipe for a security disaster. On Windows and on any other OS.
You can argue that SELinux may be able to achieve something akin to a sandbox. While it can certainly lock down an app pretty tight, it does have 2 issues: 1) It's highly impractical. Mainstream users will not be able to set up a profile and no mainstream distro has been able to supply a built-in profile which suit the needs of the general user. 2) While a profile may prohibit/allow certain calls, it cannot do so based on what the user wants to do. If FF needs to read or write from/to a directory, it will be allowed to do so always. The IE/Chrome sandbox design always denies local file system access. To be able to upload/download files the browser process must interact with a higher privileged process to do the actual marshalling of files. Obviously such a design is inherently stronger.
Also, Chrome and IE are the only browsers with any meaningful sandboxing. Chrome actually leads the pack with multiple sandbox mechanisms on Vista where it uses its own sandbox and in addition to that the Vista low integrity process mode (same as IE protected mode).
Firefox now holds the dubious honor of being the browser with the most vulnerabilities. I believe that this fact along with no sandboxing (no mitigation of vulnerabilities) and a rising market share will mean that it is only a matter of time before FF is hit with exploits. And that will be a downfall for the "secure" browser.
is also an option. Can completely lock down a PC. All changes are written to a separate "log" partition which can be reverted. Logs can be kept separate for individual users and the system. For instance you can configure Windows SteadyState to discard all user changes at each boot but allows the system to update itself through Windows Update
Doubtful (that there's anything new in this so-called powershell). At least no one has posted anything so far that can't be done easier in a modern Unix shell.
How about these:
Pipes are object-oriented. Commands are piping objects instead of plainly text. This means that
subsequent commands can refer to properties instead of parsing columns trying to get delimiters right and avoid false positives
tools/commands do not have to worry that columns may not be wide enough
you don't have to suppress headers and formatting information and
values are passed strongly typed, i.e. dates are just dates and you need not worry about ISO formats to sort correctly.
text (string) is just an object type so you can still just pipe text if you so choose.
instead of passive text the script/commands may interact with the objects. As an example, ProcessInfo objects (returned from the ps cmdlet) expose a WaitForExit method which allows scripts to wait for a process to terminate without resorting to ps loop polling or specialized tools.
First class strongly typed script language is embedded. It understands floats, objects, dates, times etc. Unlike when you drop into Perl or Python, PowerShell script still allows the use of commands with full piping embedded in scripts.
Provider/drive architecture which is extensible. PowerShell comes with providers for file system, registry, credentials store, certificate store, environment, variables, functions and aliases. Providers are user-extensible and providers also exist for Active Directory/LDAP, Exchange etc. The upshot: You can manipulate any store just like you manipulate directories and files, using the exact same commands. You can change "current location" into Active Directory, go to an organizational unit and start adding/removing members like it were files. With the exact same commands.
structured, nestable exception handling using try-catch-finally blocks.
transaction support (v2). Lets you rollback/commit changes to file system, registry or any other transaction aware provider as atomic transactions. Yes, NTFS is transactional.
script signing. By default PS will not let you run any script files unless they have been signed by a trusted authority, which can be yourself, your IT dept. or a 3rd party supplier. This can be set to only block unsigned scripts received from the internet/mail or never block (stupid).
debugger support (v2). Not just tracing but actual debugging with breakpoints, variable inspections/changes/continue etc.
Culture and internationalization support. Allows localized scripts with messages from multiple language dictionaries.
But you wanted to see something that could not be done more easily in a modern unix shell (like bash or zsh?). Let's see:
# list all empty directories below current:
ls . -r | ?{!($_|ls)}
# list all directories below current which are empty except for *.tmp files:
ls . -r | ?{!($_|ls -ex *.tmp)}
# or just read the slashdot headlines through the speakers
$wc=new-object Net.WebClient
$rss=[xml]$wc.DownloadString("http://rss.slashdot.org/Slashdot/slashdot")
$voice=new-object -com SAPI.SPVoice
$rss.RDF.item | %{[void]$voice.speak($_.title)}
# list threads consuming more than 100MB (working set)
ps | ?{$_.WS -gt 100MB}
# which 10 processes has been using most CPU?
ps | sort -desc CPU | select -first 10
# but how is their average CPU utilization since start?
#(format in a table with process name and average CPU utilization in percent with 2 decimals)
$big = ps | sort -desc CPU | select -first 10
$big | ft Name, @{ E={$_.CPU/((get-date)-$_.StartTime).TotalSeconds}; L="CPU avg"; F="{0:p2}"}
PS is definately late to the game. It was released in 2006 and until then advanced scripting on Windows required the hideous and verbose VBScript or something like it. But as you can tell PS is definately making a strong showing. It is consistent (easy when newly designed), extensible, feature-rich and yet simple to use when you get the concept.
As for the "some data structure" being transferred, that it not what PowerShell does. It transfers interfaces to objects through the pipeline. And those interfaces can be discovered and queried.
The Get-Member (it has the alias gm) will list the interface members (properties, methods,...) grouped by the distinct types of objects in the pipeline.
So the command ls | gm will tell you exactly what types of objects are in the current location and what properties/methods you can use. Furthermore you can use the Format-List * (or simply fl *) to output the values of all properties of all objects.
Slashdot Mirror
Microsofts assistance to Moonlight is actually increasing.
Microsoft helped Moonlight users get legal access to commercially licensed codecs by allowing Moonlight users to download the codecs from Microsoft's site. That way the codecs are covered by Microsofts licenses (Microsoft licences these codes from 3rd party IP companies).
Perhaps more importantly Microsoft also open sourced the control widgets for Silverlight so that the exact same controls can be used in Moonlight.
That said, Moonlight still have some distance to cover to reach SL parity. I believe they are still missing code access security (CAS). CAS is paramount when you let foreign code into your system. It forms part of the sandbox which constrain what the foreign code can do (it has to declare up front was privileges it must be granted, and during execution it cannot go beyond those privileges). I believe that is the most important missing piece.
Silverlight 3 also features hardware 3D acceleration. I don't know how far Moonlight has come there. The other parts such as C# 4 and DLR Mono and Moonlight actually seems to be not to far behind.
But another area where Moonlight may actually be more compelling than Silverlight is in the area of cross-compilation. If not already, you will soon be able to develop iPhone apps in silverlight and cross-compile them for iPhone. As Apple does not allow any VM technology into their precious iPhone garden, this is quite interesting (by being compiled to native code Moonlight circumvent this restriction). Developers can develop games in Silverlight and can use almost the exact same code base for iPhone, Windows, OSX and Linux.
Also, do remember that Microsoft develops and supports Silverlight on Intel OSX too. At present Silverlight then covers some 97% of the market (Windows + Intel Macs).
I think he was referring to "isolated storage". Basically you can allow "applicatoions" to store data locally on your machine. By default only a limited quota is granted (the application can ask for more and the user has to approve it).
The stored data is obfuscated to avoid malicious apps downloading files/scripts and then use social engineering techniques to fool the user into launching them. This allows an app access to data even when offline.
Silverlight itself executes inside a pretty restricted sandbox. Silverlight has an impeccable security record Secunia reports zero vulnerabilities in both SL1 and SL2. That is not to say that there are no vulns in SL. But at least compared to Flash it's quite good.
Even so, installing yet another plugin/app will *never* make your computer *more* secure, except when you're installing some lock-down app or firewall. Obviously any app only increases the attack surface.
Let's see about that. I'll just fire up my custom metasploit and we'll see about that. Ok. Now its probing 127.0.0.1. We'll see ho
Even UAC is a bizarre hack of a permissive userland, and doesn't use the kernel's security features.
If you can get past the idea that UAC is only the UAC prompt you will see that UAC is indeed much more, and that UAC very much so use the kernel's security features.
Among other things, UAC manipulates the security token of the process, stripping away access rights. This is what is used for both the sandboxing of low integrity processes as well as the elevation prompt.
Normal processes launched by the user is stripped of admin rights by default. Only if the user is actually an admin and only when he tries to access something which requires those rights will the prompt appear. Confirming the UAC elevation prompt will grant the access rights to the process token.
Certain processes - such as Google Chrome and Internet Explorer - are launched in low integrity mode. The process token is stripped of even more rights, preventing it from writing to the registry or to the file system except for an isolated region.
The kernel also ensures that a lower integrity process cannot send messages (or otherwise access) a higher integrity process. So while applications you start on the desktop may send messages to eachother, the IE or Chrome instances cannot send similar messages to desktop apps, even if taken over by an attacker.
Essentially Vista/7 subdivides the user's account based on what he/she is doing. Surfing the internet: low integrity. Running normal, local applications: Normal integrity. Performing admin tasks: Elevated integrity. Installing new applications: Trusted installer integrity.
I don't know about you, but this is distinctly a kernel feature in my book. Specifics here: http://technet.microsoft.com/en-us/magazine/cc138019.aspx
I have a Dell XPS notebook with built-in 3G card. I also run it on wireless and even connect the ethernet port from time to time. I use the 3G modem when I'm in a train to/from work, waiting at the station, attending meetings, conferences or when I'm on vacation. Of course the data plan costs extra, but being able to connect at all times is really, really convenient. I can even share out the internet connection effectively letting my notebook act as an access point.
Summary makes it sound like this is exclusive or that there isn't a market for it. Of course there is. Having broadband/fiber connectivity in your home does not mean that don't need on-the-road connectivity as well.
To quote the post that you just non-answered:
Right, and how about something to back up the claim that it *does* slow Windows down? That was the first assertion, so the burden of proof is on the first poster.
So how about it? Are you going to quote that "researcher" Peter Gutmann?
You've been had. The Vista DRM debacle was nothing but a smear campaign. Try reading someone who actually researched the topic as opposed to someone who just went with what he could find of anecdotes on random blogs. Ed Bott has made a series of well-investigated rebuffs of Peter Gutmanns diatribe: Read "Everything you've read about Vista DRM is wrong (3 parts"):
Or this: "Busting the FUD about Vista's DRM": http://blogs.zdnet.com/Bott/?p=284
The short version:
For what it's worth, I don't believe that interoperability with OpenOffice was ever on Microsofts agenda. The political climate (skillfully navigated by Sun/IBM) dictates that an office suite in more and more states and public institutions must be able to check the "ODF compliant" box.
The problem is that ODF was pitted as a standard which would guarantee interoperability for office documents. It was also sold pitted as a standard which would guarantee that document fidelity across different, competing implementations and across different versions.
Those were good promises. I think it has taken a lot of people by surprise (myself included) that
1) the standard is clearly not yet complete enough to guarantee these goals
2) the primary implementation - from which the format is derived - is not in compliance and indeed writes application specific extensions into the documents which directly affects the fidelity of the documents (i.e. it will *not* print the same on a different implementation.
No, you may wish for Microsoft to aim for OpenOffice interoperability. But they really only need to check a box to satisfy legislators. That the box isn't big enough is a failure of the standard.
No, we're faulting them for following the specs to the letter and at the same time going out of their way to make sure their technically compliant implementation still doesn't work with all the other, existing implementations.
So, a standard was proposed and decided upon. It was then used to criticize Microsoft Office and used as an argument to urge government and public institutions to drop MS Office and use ODF compliant software. The argument was that
1) only a standard would ensure a durable document fidelity - i.e. that the document also in the future would be interpreted the same.
2) only a standard could guarantee interoperability.
Only, the ODF standard obviously failed in both of those aspects. And now the battle cry is that Microsoft should follow a draft, non-official standard or even a specific implementation because it will probably be standardized? gee, is it any wonder Microsoft had trouble succumbing to those terms? "Just write the dotted line, we'll fill in the rest later, don't you worry". Sorry, but ODF was (and is) still driven by Sun/IBM and it would be naive not to think that they wouldn't use that against Microsoft.
What is wrong about asking OpenOffice to follow the specs?
ODF does, for the most part, follow the specs.
For the most part. For the most part??? Have you any idea what would be lopped in Microsofts direction if they claimed ODF compliance and followed the standard for the most part??. I call hypocrisy.
The problems between OpenOffice and MSOffice's implementations are that ODF implements a newer version of the spec and MS hasn't caught up to that
Oh, please! At least be honest! You want Microsoft to adhere to an yet undecided, still draft spec. A spec which incidently has show remarkably little progress. The draft spec defines the structure for a formula language, but the actual formulas are still just "whatever is in OpenOffice". Wasn't that exactly the argument against the OOXML spec where some of the renderings specs in the early drafts were defines as "whatever Office 97 does". Sounds suspiciously alike. Fortunately those definitions were eradicated and replaces with proper definitions during the OOXML standardization process.
MS may, technically, be minimally compliant with the spec, but it is clear they went out of their way to be as minimally compliant as possible to make their version as incompatible and unfriendly as they could manage while still being within the spec.
It is not clear at all that they went out of their way. That's pure speculation. But that is really not the issue here. The idea behind the ODF standard was not to make everyone compliant with whatever OpenOffice does, but to make all implementations compliant with the standard. I suspect that Microsoft may smile in secret at this jab against Sun/IBM, but really, strict ODF compliance is their end goal because that is what can make or break contracts with governments and public institutions. It's just a box to check. Interoperability with OOo was never (I believe) their goal. The standard should make sure of that. OOXML does.
Yeah, but it was an attempt to level the playing field and let products win based upon merits instead of criminal leveraging of monopolies. I don't understand why people have such a hard time understanding antitrust laws and how they work and why we have them.
Oh, but that is perhaps the most positive outcome of all of this. It finally forced Microsoft to make their file formats public, to dispose of IP protections on the office format and to commit to an open standard and to continue to do so. I feel that was a tremendously positive result, and I'm deeply grateful to Sun, IBM and OpenOffice for forcing this upon Microsoft. At the time of the great debackle there were so much FUD in th
I'd say that it had a bad smell of Hypocrisy. If the standard doesn't cover important(I dare say) areas such as the friggin formula language, what good is the standard?
No, the author is trying to preempt the obvious and very valid argument that if the standard didn't cover this and implementers need to reverse engineer a specific implementation (OpenOffice), maybe the standard wasn't good enough?
The author is making silly analogies with someone willfully going through hoops (investing time) to sabotage interoperability with an implementation in which the implementor has chosen not to invest time and effort reverse engineering and testing functionality which is clearly outside the specification.
So now you're saying that the language for formulas should be defined by an implementation as opposed to being defined in the standard?
So, what happens when Microsoft comes up with a new formula and starts generating documents with that formula in it? Will other implementations be required to understand that as well?
Maybe, just maybe, there was a reason for OOXML to be longer than ODF. Maybe it is because it is more complete on issues such as this? But everybody were caught up ridiculing OOXML and arguing against competing standards.
IIRC the ISO committee hinted that there were several precedents of competing standards, and that the better (i.e. more complete one) would eventually become the primary standard.
What good is a standard if we still have to reverse engineer applications to achieve interoperability?
So let me get this straight:
What is wrong about asking OpenOffice to follow the specs? How about ODF getting an ovarhaul to weed out ambiguities and to properly
What goes around comes around. ODF was initially just a clever assault launched by Sun and IBM. With one strike they propelled ISO into relevance and took Microsoft completely off-guard. But customers saw the light and started demand good standards. Only, it is now evident that ODF and the posterchild OpenOffice were never prepared for the success.
OpenOffice and derivatives, Sun and IBM just have to eat their own dogfood. Admit that the "perfect" ODF was at least partly a hype.
We've seen from the browsers what "lenient" parsing can lead to. It is called tag soup. Requiring all products to leniently compensate for ambiguities in the spec or faulty implementations are definately the wrong path!
The chickens are coming home to roost. Suck it up. Fix it instead of point fingers.
Tap the Alt key or press-and-hold it. Small letter shortcuts will show up next to all of the functions on the ribbon. Having learned the shortcuts simply press and hold the alt key (or tap it again) and key in the shortcut sequence next time.
To all those who don't get it, go look up "time unpatched" for each of IE's vulnerabilities. That is, time from when they were reported to time when they were patched. That's the time Microsoft left you swinging in the wind.
Not exactly. They actually left you "swinging in the wind" since they introduced the vulnerability which would often be since the product release. And that goes for any vendor, Microsoft, Apple, Mozilla, Ubuntu/Linus etc.
If a vulnerability is responsibly reported, the days following the discovery are no more risky than the days preceding it. Naturally each day counts, but there are also other concerns.
We just saw Firefox 3.0.9 introduced a new vulnerability which had to be patched immediately. That's not a desirable situation. For an enterprise a patch gone wrong can be far worse than being exposed to a responsibly disclosed vulnerability. We want to be exposed to vulnerabilities as little as possible (fewer vulns, shorter period), but we also don't want patches destabilizing our infrastructure.
Basically it is a judgment call. And unfortunately not one you can solicit opinions from the public/customers as that would defeat the purpose and forgo the decision.
BTW, even Linus Torvalds will not disclose every vulnerability. He has publicly stated that if he sees a vuln he will just fix it, and that he sees no need to jump through hoops to tell anyone about it. (a MO which may lead to the undesirable situation of bad guys being tipped of by diff'ing the source tree and figuring out the vuln before the fixes makes it through the various distributions).
Indeed, different OSes comes prepackaged with vastly different extra software. Especially many Linux distros comes with OpenOffice, Gimp, etc.
Although they haven't spelled it out literally, the methodology IBM used in their analysis was to compare the "core" operating systems. As an example they used "Linux kernel" and not a distro with any extra software. That way no office suites, browsers, media players etc. were considered. Just the bare bones operating systems with basic services. I suspect that in the case of Linux and other *nixes this doesn't even include the desktop manager whereas for Windows and OS X the stats will include any vulnerabilities from the GUIs.
But you can check the IBM report for yourself here: http://www-935.ibm.com/services/us/iss/xforce/trendreports/xforce-2008-annual-report.pdf
The report also contains some good insights on the economy of exploits.
You have to read these with caution, though. Microsoft has been trying to get the vulnerability count down, and one way of doing this is merging several vulnerabilities into one. It looks good on paper, but it does not make the product any more secure.
Perhaps you would look with caution, too? You are talking about advisories or bulletins. They are often aggregated. However, secunia lists a count for actual vulnerabilities. And those were the numbers I quoted.
And even in Microsofts own bulletins (not the advance notices) the individual vulnerabilities are clearly listed and identified with CVE references. CVEs are not aggregated, not from Microsoft and not from anyone else.
That being said, the recent product certainly show improvements. They absolutely beat Java and Acrobat, when it comes to security. I think the comparison with Firefox may be uneven, though, because the Firefox guys class just about anything as a potential security issue, just to be on the safe side.
So does Microsoft. An uncontrolled browser crash is a potential vuln. But you're right, if the bug is handled in a controlled fashion (i.e. caught exception) it is probably not classified as a vuln but rather a bug. I am not aware that Mozilla would do it any other way.
I haven't tallied by the the severities of the vulnerabilities. Theoretically all of the FF vulns could be "less critical" whereas all of the IE ones could be "highly critical". But I doubt it. Anyway, it's food for thought. I don't think we should give Microsoft nor Mozilla free passes.
You haven't been paying attention to the way Microsoft works, have you? This has been typical for .... ummm .... as far as I can remember. Ship first, patch later and frequently.
Erm. Then you haven't been paying attention to the way Microsoft have worked for the past 5-6 years, have you? They have seriously pulled themselves together since the code red, nimda and initial IE6 days. I know that it's a popular myth that Microsoft software is swiss cheese, but security analysts are starting to point at Microsoft SDL (Secure Development Lifecycle) as an example on how to do it. Independent analysts, i.e. IBM, researching vulnerability reports, have for the past 3 years pointed out how Windows XP and Windows Vista are actually the operating systems hit with the fewest vulnerabilities (but still most exploits).
Looking at vulnerability stats at secunia shows that Microsoft QC have improved drastically across their entire product portfolio:
On the whole Microsoft seems to do pretty well and considerably better than their competitors in all of the above areas. And no, Microsoft does not hide vulnerabilities. They may delay publication in a responsible disclosure, but any MS admin will tell you that they are very specific about each vuln in their patch bulletins. Microsoft cannot slip a "fix" through, as they have to provide enough information for admins to take a decision whether to block or allow a given patch based on security against stability (like in fewer changes). And Microsoft does not patch "frequently". They patch 12 times a year + emergency patches. This schedule has in general been well received by admins and several other vendors are now following the same schedule.
Nah, powershell exposes a unified object model. Although powershell itself is actually written using .NET it wraps .NET classes, COM classes and WMI classes in it own dynamic-aware classes. So, in a sense the powershell object model is a new object model on top of the others. It just happens to be coded in .NET.
While the term "kernel objects" is not very accurate, between Win32/COM, .NET and WMI, Windows nevertheless exposes most functionality of the operating system in an object oriented fashion. I think that is what GP was alluding to.
This is in contrast to both Linux and OSX which use text based pipes (although from a pure programming perspective OSX can be used OO) and it is also the reason why it makes a helluva lot of sense for PowerShell to use object pipes instead of plain text pipes.
There are actually a number of advantages to using objects:
1) they can be "live" meaning that if you pipe a FileInfo object to another tool that tool can directly invoke methods for deleting, appending, renaming etc. Likewise a piped ProcessInfo object (the result of a ps command) will allow any cmdlet along the pipeline to invoke methods to e.g. retrieve extra information, enumerate threads, change priorities, kill and whatnot.
2) results from tools need to be funneled through a narrow text based pipeline. Information "expensive" to retrieve (like enumerating threads and/or handles of a process) need not be retrieved by the initial ps command. If any tool along the pipeline need that information it will be retrieved when the "getter" is called (lazy evaluation).
3) no stupid errors because all information must be serialized to a delimited text format. File names, process names etc. can actually contain spaces without breaking parsing tools. No culture dependent parsing. Objects can readily contain properties of DateTime or TimeSpan types which can be reliably sorted and compared.
4) same advantages as using OO programming languages: the objects readily exposes (you can query for members) which member properties and methods they support. This means that actions can work in a object-action syntax rather than the usual action-object. It also means that methods (the actions) can be overloaded and result in a more consistent view of the systems objects.
5) objects contains metadata and are queryable. Instead of an "id" for a process - which looks just like any other integer number you work with the actual wrapper abstraction for the process. In the case of the id you have no further information as to what it denotes. With the object such information is readily available.
..., and is one of the early web applications to actually use something like AJAX to give you the feeling of using a desktop application.
More aptly, is was THE first AJAX application. It doesn't get earlier than that.
This was years before it got its spiffy name. XmlHttpRequest (the linchpin in AJAX) was invented by Microsofts email client team to support Outlook Web Access. Being invented for IE it was (and still is AFAIK) a COM object which could be created from JavaScript in the browser. Mozilla later copied the idea and made XmlHttpRequest a first class citizen, but kept the name. The rest is history.
While I agree with most of your points, I have to take issue with no. 7:
7) This is linux and not windows. Bash is much more powerful than the pitiful shell windows provides.
It's rather newish (2006) but IMO PowerShell generally blows bash and all other Unix shells out of the water. Arguably, PowerShell is much better for Windows, as more APIs in Windows are object-oriented and thus fit better with PowerShell.
Take a look at my sig. It's a one-line, slashdot sig fitting (OP has a point: If you are handling files with spaces in them, *many* scripts will break down due to the fact that *nix shells pipes are text-only and that many tools by default parse using whitespace as delimiters. In a shell with object-oriented or structured pipes this will not happen.
Sorry for chiming in, but it is kinda my pet topic at the moment.
If you can execute in the applications context, I think you can write to the preferences files - even if the app is in a sandbox.
No, not in a sandbox. That\s the difference between something like SELinux and a real sandbox. With SELinux you will be allowed to do what you legitimately need to be able to do. In a sandbox you will have to ask the broker process to perform the privileged operations. Neither Chrome nor IE let the rendering process access the local file system. Instead they supply a broker/helper process. Typically this process will interact with the user, i.e. if downloading a file it will display a dialog or visual element to let the user choose if/where to download the file to.
You are right that if you protect Firefox with SELinux, it still needs to be able to access the preferences store. Thus a contaminated instance will be allowed to do the same, i.e. it will be able to change settings without user interaction or consent.
Chrome actually takes it one step further, isolating each tab in its own process. This (in theory) prevents cross-contamination between tabs. If an attacker successfully compromises one tab he can still not intercept communications from/to the other tabs. While IE has a sandbox it doesn't protect individual tabs, merely the browser itself and the file system.
Per the contest rules it wasn't necessary to break out of the sandbox, so at this point it is not clear that that happened. Simply executing code in context of the application (browser) would be enough. You can still do a lot of damage inside the browser, i.e. install password/certificate snooping, monitor and inject traffic etc. But it all ends with the browser session. You cannot read/write users' files much less compromise the machine.
Unlike Firefox, Opera and Safari, Chrome and IE actually has such a sandbox. Chrome actually has a 2-level sandbox and a process-per-tab while IE only has a single sandboxed process common to all tabs.
In addition to that IE has a really big supply of extra defenses such as heap encryption, various stack overflow protections, mechanisms designed to foil exception handler exploitation etc. At least some of these must have been broken in the attack against IE8. Recently a couple of security researchers demonstrated how most (if not all) of these mitigation mechanisms (except for sandbox) could be broken by leveraging perfectly valid code to reduce entropy (most of these mitigation mechanisms work by introducing entropy or encryption thus lowering the chance of a successful attack)
Firefox, Opera and Safari has no sandbox and practically no extra mitigation mechanisms to speak of, except for those offered by the operating system. Again, OSX is a the bottom of the heap here, with practically NO extra mitigation techniques. Vista offers the most, especially on 64bit.
For the last couple of years, Firefox (not IE) has been the browser with the most vulns. Combine that with the fact that it has no sandbox, no extra mitigation techniques and that it relies heavily on extensions and plugins the quality of which cannot be controlled by Mozilla. That's a recipe for a security disaster. On Windows and on any other OS.
You can argue that SELinux may be able to achieve something akin to a sandbox. While it can certainly lock down an app pretty tight, it does have 2 issues: 1) It's highly impractical. Mainstream users will not be able to set up a profile and no mainstream distro has been able to supply a built-in profile which suit the needs of the general user. 2) While a profile may prohibit/allow certain calls, it cannot do so based on what the user wants to do. If FF needs to read or write from/to a directory, it will be allowed to do so always. The IE/Chrome sandbox design always denies local file system access. To be able to upload/download files the browser process must interact with a higher privileged process to do the actual marshalling of files. Obviously such a design is inherently stronger.
Also, Chrome and IE are the only browsers with any meaningful sandboxing. Chrome actually leads the pack with multiple sandbox mechanisms on Vista where it uses its own sandbox and in addition to that the Vista low integrity process mode (same as IE protected mode).
Firefox now holds the dubious honor of being the browser with the most vulnerabilities. I believe that this fact along with no sandboxing (no mitigation of vulnerabilities) and a rising market share will mean that it is only a matter of time before FF is hit with exploits. And that will be a downfall for the "secure" browser.
It's available for XP and Vista (32 bit) free from Microsoft: http://www.microsoft.com/windows/products/winfamily/sharedaccess/default.mspx
Doubtful (that there's anything new in this so-called powershell). At least no one has posted anything so far that can't be done easier in a modern Unix shell.
How about these:
But you wanted to see something that could not be done more easily in a modern unix shell (like bash or zsh?). Let's see:
# list all empty directories below current:
ls . -r | ?{!($_|ls)}
# list all directories below current which are empty except for *.tmp files:
ls . -r | ?{!($_|ls -ex *.tmp)}
# a better slashdot rss reader
$wc=new-object Net.WebClient
$rss=[xml]$wc.DownloadString("http://rss.slashdot.org/Slashdot/slashdot")
$rss.RDF.item | ?{$_.creator -ne "kdawson"} | fl title,description
# or just read the slashdot headlines through the speakers
$wc=new-object Net.WebClient
$rss=[xml]$wc.DownloadString("http://rss.slashdot.org/Slashdot/slashdot")
$voice=new-object -com SAPI.SPVoice
$rss.RDF.item | %{[void]$voice.speak($_.title)}
# list threads consuming more than 100MB (working set)
ps | ?{$_.WS -gt 100MB}
# which 10 processes has been using most CPU?
ps | sort -desc CPU | select -first 10
# but how is their average CPU utilization since start?
#(format in a table with process name and average CPU utilization in percent with 2 decimals)
$big = ps | sort -desc CPU | select -first 10
$big | ft Name, @{ E={$_.CPU/((get-date)-$_.StartTime).TotalSeconds}; L="CPU avg"; F="{0:p2}"}
PS is definately late to the game. It was released in 2006 and until then advanced scripting on Windows required the hideous and verbose VBScript or something like it. But as you can tell PS is definately making a strong showing. It is consistent (easy when newly designed), extensible, feature-rich and yet simple to use when you get the concept.
As for the "some data structure" being transferred, that it not what PowerShell does. It transfers interfaces to objects through the pipeline. And those interfaces can be discovered and queried.
The Get-Member (it has the alias gm) will list the interface members (properties, methods, ...) grouped by the distinct types of objects in the pipeline.
So the command ls | gm will tell you exactly what types of objects are in the current location and what properties/methods you can use. Furthermore you can use the Format-List * (or simply fl *) to output the values of all properties of all objects.