Niten

I've had the same experience with my Incredible. The fact that CyanogenMod 7 is Android 2.3 based, while there isn't an official Gingerbread ROM for the phone, is probably also a factor.

Ironically requiring that they make more copies, if this is true.

I agree (and I have no idea why you're being downvoted). I don't always need Flash on my phone, but in the situations where I do I'm really grateful to have it. And click-to-flash is the ideal way of handling this.

Oops, thanks... missed that last paragraph there.

Too bad he didn't get into any of the stuff that really makes C# nicer than Java, in my opinion: lambda expressions and closures, LINQ, expression trees, dynamic typing, type inference, P/Invoke vs JNI.

Also the event / delegate thing makes C# really nice for GUI stuff.

He/she never said "biggest". But an increase in corporate penetration would increase the value of OS X as a malware target, and that is what drives malware.

Wait, am I missing something here? How is this anything but a patent on the not-exactly-cutting-edge concept of a web application?

Even if you think that performing some rendering computations server-side is somehow a patentable innovation, there's plenty of prior art out there already doing so. Score another one for the broken patent system.

I agree... although it would be nice if they would step up for their customers in this regard, I just don't see a scandal here. (That's just The Register's style of reporting I guess, not to diss them or anything.)

However, the letter itself is interesting in that it confirms Mac malware is becoming a real issue.

> I don't think antimalware is anything I'd ever want to run on a computer I control.

Why not? I mean this as an honest question.

EDIT: If you're concerned about performance or system resources, try a PC with MSE sometime, I think you'll be pleasantly surprised at how unobtrusive good antimalware can be.

> nope. by the user running an installer when requested by a browser ad popup.

I agree that this is how most malware happens in general, but I was talking specifically about the subset of malware installations that are drive-by downloads, i.e. which are performed without user interaction:

http://en.wikipedia.org/wiki/Drive-by_download

What I mean to say is that most of those are exploiting third-party software (Java, Adobe Flash and Reader) rather than Microsoft stuff these days.

Oh they absolutely would. Heck, Windows Defender is the same engine as MSE, they just had to limit its functionality to keep from getting sued. They were even threatened by the third-party antivirus companies when they promoted a link to MSE in Microsoft Update.

But hopefully they can take a more proactive course now that the DoJ's oversight is ending:

http://arstechnica.com/microsoft/news/2011/04/department-of-...

> An uptick in users installing adware on their computers (yes, you have to manually install it) is a far cry from having a platform blighted by drive-by infections and autonomously spreading worms as Windows was in years past.

Well yes, but lately how are these drive-by installations happening? Mostly through holes in third-party software. My concern, as a Mac user, is that there's no fundamental reason it should be any harder to attack OS X this way; it's just that up until now Windows has been a vastly more profitable target. And that is changing.

If you're a careful and conscientious user I'd honestly say you're safer on Windows at this point, because Windows is used to being attacked. It's used to defending itself against this kind of threat. You have this ecosystem of powerful antivirus programs like MSE or AntiVir that update themselves constantly, and innumerable other third-party tools such as Secunia PSI as preventative measures, and these just don't really exist on OS X yet. Windows also yet has some exploit mitigation facilities that OS X lacks, such as ASLR and kernel patch protection.

It will be a while before OS X has developed such an ecosystem of its own, and we just have to hope the adjustment period won't be too painful.

Most Windows viruses these days have the exact same attack vector, simply tricking the user into installing them. All we're seeing here is that: (1) Despite the marketing, the Mac is not magically immune to these things any more than Windows is, and (2) now that OS X has obtained a reasonable market share it's finally become worth attacking.

Neither of these things should be surprising to anyone, and hopefully the antimalware situation on OS X will improve before progressively more insidious Mac viruses are released.

> Microsoft doesn't remove malware that Windows users install either.

Yes they do:

http://support.microsoft.com/kb/129972/en-us

"Call 1-866-PCSAFETY or call 1-866-727-2338 to contact security support."

> Two hundred clueless posts on a web forum out of a userbase of millions doesn't mean there's a "malware explosion," as he described it. Why are people falling for this flamebait?

If Apple is issuing special instructions to its support staff about this malware, then clearly this is a pronounced problem.

True. I wouldn't claim it's any suckier than PHP, for example. Both "suck", but both have their uses.

As much as VB6 sucks as a programming language, this will honestly be useful to a lot of people out there. Because whether it sucks or not, if you've inherited a VB6 codebase then that's what you have to work with.

Finally signed on for a Netflix trial so I could try this on my rooted Incredible running CM7. Works great.

To play devil's advocate, this isn't out of the question.

1) Macs do tend to run hotter than PCs, and this could decrease HDD lifespan.

2) We've seen in the past that OS-specific power management settings can be detrimental to hard drives, as with this famous Linux bug: https://bugs.launchpad.net/ubuntu/+bug/104535 Although I doubt it's actually the case, it's possible in principle for drives to wear differently under OS X than under Windows.

"Chrome's sandbox" is the Windows "low integrity mode" mandatory access control mechanism. If the process elevation was achieved through a privilege escalation attack against this mechanism rather than by attacking the non-low integrity mode Chrome master process, this might not be a bug in Chrome at all...

I think you're being too loose with language here. The implication was that Google doesn't use Windows because Google is cutting-edge; this is a claim about the technical merits of Windows, not the direction of Microsoft's leadership.

Well it makes sense, given that Google is predominantly a linux-based company.

But it's a fallacy to equate "cutting edge" with "not Windows". Windows may not be as fashionable in the same way that Macs are with the Starbucks/college campus crowd, but it's certainly no less "cutting edge" a desktop operating system than OS X or Linux.

That's absurd. The general public doesn't know or care about the difference between Android versions any more than they know about the difference between iOS versions.

"Big government" in the most literal sense :)

I wouldn't assume that. I think the big deal here is that they managed to break out of the Windows sandbox; that's what makes the exploit particularly interesting. The same vulnerability could exist on Linux too, but they just didn't invest the time in developing and demoing an exploit there too.

Or maybe not. I'm just saying, we can't assume either way.

Well clearly there are two things going on here, assuming VUPEN is on the level:

1) A remote code execution exploit in Chrome

2) A privilege elevation exploit allowing the hijacked browser process to break out of its mandatory access control jail

Number 1 is of necessity a bug in Chrome itself (or a plugin). Number 2 is probably a vulnerability in the Windows sandbox, but it could instead be that they found a way to successfully attack the small part of Chrome that runs outside low integrity mode. They weren't specific as to the details.

This is, again, at the very least a remote code execution hole in Chrome, and there's no fundamental reason Linux or OS X should be invulnerable to the same hole. That Chrome on Windows is less secure than on Linux or OS X would be the wrong thing to take from this; the point of this demo is that VUPEN accomplished the feat of bypassing all the security mechanisms protecting Chrome on Windows, whereas on the other platforms you have fewer of these mechanisms in the first place (no real ASLR on OS X, no Chrome sandboxing last time I checked on Linux).

If you want to be safe, run a VPN on the phone and route all your traffic, tethered or not, through that.

Someone probably did a focus group and found out people got 47% more warm-fuzzies from the word "promise".

> however it's this [...] that I think will keep it from being especially useful on non-Windows platforms.

Sure, and I acknowledge as much in my post above, that PowerShell's object orientation is most appropriate for the Windows environment. But even if you aren't concerned with COM, I still think PowerShell is pretty nice, and I wouldn't mind seeing a port to Linux. So for that reason I welcome its addition to the Community Promise.

> TBH I wish they'd added features to IronPython instead of making a new syntax, but such is life.

I don't think that would have worked well...

You have to keep in mind that PowerShell is intended to be used interactively, and this has all sorts of implications for the language design. For instance when you type

    PS > foo

at the PowerShell command line, "foo" may be a pure PowerShell function, but it could also be a cmdlet, or an external command somewhere else on the system. If this were a straight Python REPL instead, you'd have to do external calls differently from Python function calls, like so:

    Python > system("foo")

and that gets old real fast. Likewise you need to allow bare strings and ditch parentheses for function calls so you don't wind up saying cd("C:\"). You'd also have to come up with a more succinct syntax for chaining Python generators assuming that's what you want to use as a substitute for PowerShell's cmdlets. Plus there are concerns like, hey, we can't use the backslash as a string escape operator, because suck as it may, that's the traditional path separator on Windows, so we've gotta make it something else. By the time you're done, it's not even Python any more.

And on top of all that: in my opinion, as much as I love Python, significant whitespace really sucks for REPLs...

So I don't think Python would have been an appropriate choice for a new Windows command line interface. But the great thing about PowerShell is that even if it isn't interactive Python, you can always implement cmdlets for it in IronPython (or pretty much any other .NET language)...

This isn't pointed at you, keyle, but here PowerShell seems to be one of those things that's universally panned by people who don't understand it, or who refuse to give a serious chance to anything that isn't a traditional Unix shell...

To answer your question, PowerShell's big win is that it's an object-oriented shell on top of .NET. Where the Unix shell pipes flat data, PowerShell pipes .NET (and COM) objects.

In practice this means things that may require complicated and often fragile text-wrangling in the Unix shell are straightforward and robust in PowerShell. For example, suppose you wanted to kill all processes with a private working set greater than 1 GB:

    ps | ?{ $_.PM -gt 1GB } | %{ $_.Kill() }

Here ps returns a collection of all current processes, then pipes it to the where-object cmdlet (abbreviated "?") which filters the collection to those with a private working set greater than the given size. The filtered collection is then piped into the foreach-object cmdlet ("%") which invokes the Kill() method on each object passed in – these are real .NET objects being passed around, so you can invoke methods, set properties, etc.

You can get the same result with a Unix shell script, but you have to be careful to count the columns output by ps correctly, skip the output header, pass it through awk, save the corresponding PIDs and then invoke the kill command on them... and then it all breaks if you run it on a different Unix system where ps outputs a different formatting. In practice you usually leave the shell environment and write a Perl or Python script instead for this sort of thing.

In PowerShell you can directly instantiate .NET and COM objects, and you can implement your own cmdlets and modules either in the PowerShell scripting language or in any .NET language like C# or F#. So e.g. you can access the .NET class libraries to get the time as so:

    [System.DateTime]::Now

And this makes PowerShell handy for interactively developing .NET class libraries (at least until C# gets a real REPL, and if you aren't using F# anyway). Of course this object-oriented approach is all the more necessary on Windows, which is inherently an object-oriented system (think OLE automation, WMI, etc., let alone .NET) than it is on Unix-based systems.

Some people will complain about the PowerShell scripting language... and sure, it's not perfect, but I think the team did about as good a job as possible satisfying the various requirements involved in building a new Windows shell language that could be used both interactively and as the basis for writing scripts. Superficially the language is heavily influenced by Perl, and while I'd still rather use Perl for "serious" automation tasks, PowerShell gets the job done... and it's nowhere near as ugly as scripting in the traditional Unix shell, nevermind the old Windows command shell.

For more on the design rationale, in the words of one of PowerShell's creators:

http://stackoverflow.com/questions/573623/powershell-vs-unix...

Ha! Suing competitors over dubious patents; pushing for legislation to punish people for using their own hardware how they see fit; trying their hardest to keep people from using iPods and iPhones with anything but iTunes; designing special screws to lock people out of working on their own Macs and iDevices, increasing service revenue; abusing their control over the App Store to keep out competitors; instituting a new App Store policy to force content providers to pay 30% to Apple, and disallowing providers from raising prices in the App Store vs. on other platforms to cover this cost...

None of this sounds the least bit shady to you?