TippingPoint has long been a proponent of information technology security, especially known for its Zero Day Initiative bug-hunt rewards program in which security researchers can earn thousands of dollars by revealing new vulnerabilities to TippingPoint, who in turns contacts the faulted software developers to get them to patch the holes in their code.

But a recent perusal in the ZDI database for high-risk vulns still sitting unpatched after more than a year after disclosure has grated on some nerves.  Some of those privately disclosed security holes have even gone as many as three years without being fixed by their respective software vendors.  And that’s just no good.

TippingPoint had been trying to be responsible, keeping the disclosure of the bugs private, giving their creators time to fix them to keep everyone safe without going full disclosure and letting the hackers also know of these vulnerabilities.  But after seeing too many software companies sit upon their laurels and do nothing about their holes, TippingPoint has had enough.

The new ZDI police will still be to privately contact software companies, but to only give them six months of privacy to correct their flaws.  After that six months, if no extension is agreed upon, TippingPoint will turn around and give full disclosure of the bug to the world at large, giving third parties an opportunity to fix the holes that a software vendor refused to act upon.

While many proponents (including myself) laud this tough-on-bugs approach, opposition to the “full disclosure” method (such as Microsoft, of course, inventors of security through obfuscation) argue that set timescales don’t work because some bugs take longer to fix and test than others, and that hackers can also use the disclosed information to make their job of getting into your computer easier.

And these are valid points.  But then, that’s probably why TippingPoint in fact has a method in place to file for an extension to that six month timeline.  TippingPoint seems to make it clear that if Microsoft can make a convincing argument on why they can’t fix their security hole in a mere six months, TippingPoint will be more than happy to extend that timeline to give them all of the privacy they need.

Meanwhile, there’s the other end of the spectrum.  Recently Google has expressed a policy similar to this new one from TippingPoint, but with a mere 60 days, just two months, of privacy, a much tougher deadline to meet.

Intel has recently upset a few people over at nVidia by releasing a technical paper, Debunking the 100X GPU vs. CPU Myth:
An Evaluation of Throughput Computing on CPU and GPU.  Actually, truth be told it’s more than nVidia that Intel is stepping on the toes of.  That’s just where they started.

With the advent of graphics cards (GPUs) being able to execute program code instead of just draw graphics now, a lot of people are finding that the graphics cards with tons of floating-point math units capable of processing amazing amounts of per-pixel operations and having access to a cache of very low-latency high-speed RAM to play with can offer some absurdly high parallel processing power to applications now that their architecture is available through general-purpose programming APIs.  Processing power which traditional computer processors (CPUs) just can’t match, in some applications.

Only, not according to Intel.

Intel’s tech paper rather somehow finds that GPUs are only two and a half times faster than their best CPUs.  nVidia begs to differ. And frankly, one can see nVidia’s case.

To start with, let’s look at the hardware Intel chose to compare.  In Intel’s corner is the magnificent Intel Core i7-960.  It’s the most state-of-the-art desktop CPU from Intel.  It comes with 4 cores, each capable of Hyper Threading, for a virtual total of 8 cores.  It runs at 3.2GHz, self-overclocks to 3.46 GHz, has 8MB of cache, and currently retails for around $570.

In nVidia’s (and really, all GPUs-used-as-GP-processors) corner is the nVidia GeForce GTX 280.  Umm … which is so last season.  Not nVidia’s the latest and greatest.  Still, it has 240 CUDA cores, runs at 1.3GHz, and has 1GB of cache running at 1.1GHz.   It currently retails for around $300.  Yes, it costs half as much as Intel’s best CPU.  Because it’s not the latest technology.

For the record, nVidia’s latest graphics card is the nVidia GeForce GTX 480.  It runs on nVidia’s new Fermi architecture.  It has 480 CUDA cores, runs at 1.4GHz, and has 1.5GB of cache running at 1.8GHz.  It currently retails for around $500.  But Intel didn’t compare to this GPU.  Gee, I wonder why not…

So already we see a grave technological disparity here.  Intel chose their latest and greatest, while choosing nVidia’s last-season runner-up.

But that’s not the only point of contention.  Intel chooses a number of CPU-specific benchmarks.  Okay.  Not exactly the fields where people are trying to optimize for GPUs, but this is Intel, so of course they’re concerned with their own bailiwick and not the stuff people are actually using GPUs for.  So I’ll give them that much.

However, the next major point to ponder, nowhere in Intel’s paper is given the information on how the code was compiled and built.  We have no idea what optimizations are and aren’t being done, for Intel or for nVidia.  So for all we know, the code could be highly optimized towards Intel and not optimized at all for nVidia.  We simply don’t know.  It’s a rather glaring omission from Intel to have left this information out in a performance comparison.

And, of course, we then come to the final point of contention, Intel’s conclusion.  Intel concludes that the performance gain of using a GPU over a CPU is only 2.5 times better performance.  Even though their own benchmark result comparison chart is scaled to 6 times the performance of the Intel Core i7-960, and one of the benchmarks actually reaches 14.9 times greater performance.

Intel CPU to nVidia GPU Benchmark Performance Comparison

So then which is it?  Only 2.5x faster?  Or potentially 14.9x faster?  Or more?

And that’s using last-gen graphics technology for comparison, with half of the cores, less memory, and slower clocks all around.  On software where we have no way of knowing how it was (or wasn’t) optimized, so an invisible bias may or may not also be involved.  In benchmarks undoubtedly hand-picked by Intel.

It’s no wonder then that nVidia, in their response to Intel, prefers to use real-world applications in its rebuttal.  These are projects actually performed by real people, with real results, that are documented and reproducible.  And the performance gains range from Cambridge University seeing 100 times the performance, to Massachusetts General Hospital seeing 300x gains using GPUs over traditional CPUs.

There’s a reason why so many people are interested in this technology and are using it.  It’s sad to say that even the worst possible biased view against using a GPU in mathematical applications is still 2.5 times better than a CPU.  And the best?  A hundred times better or more, apparently.

Sorry Intel, but even if we believed your FUD of only a 2.5x performance gain, it’s still an Epic Fail if you’re trying to convince us not to look into using nVidia’s GPUs instead of just your CPUs alone.

There’s small reason to rejoice today if you’re a software developer.  Apple has loosened up it’s no-interpreted-code policy in the iPhone SDK used for development of apps on the iPhone, the iPod Touch, and the iPad.

The old iPhone SDK end user licensing agreement (EULA) stated quite clearly and adamantly that, “No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).“  This prevented anyone from using languages like Adobe’s Flash or Sun/Oracle’s Java.  Or Python.  (My personal favorite language.)  Amongst many others.  It also prevented the use of third-party development tools such as Adobe’s iPhone packager, which converts Flash scripts into native iPhone machine code.  Or third party libraries such as .NET, Mono, Qt, etc.

It’s a limitation that many developers feel is not only senseless and needlessly inhibitive, but even has the government fighting (DoJ and FTC) for the chance of an antitrust investigation into Apple for their non-competitive practices.

The new iPhone SDK however has a change of heart.

Kind of.

Sort of.

Maybe.

Just a little bit.

A few minor changes of wording in the iPhone SDK leave a little bit of theoretical wiggling room.  Such as, “Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).“  Which makes it sounds as if, theoretically, you could request from Apple a waiver to release your interpreted-code app.

Maybe.

Because then that theoretical possibility of using an interpreted language is further qualified in the iPhone SDK with, “Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.“  My own emphasis on the key qualifiers there.  So of course you still need to write the majority of your code in an Apple-approved language.  You still can’t use any third-party development tools, libraries, or languages.

It still doesn’t really fix anything.  Except for perhaps a few rare instances of development, quite possibly in minor things like spam filters, spell checkers, and small pieces of engines used in games.

But maybe it sounds a lot less closed to antitrust investigations perhaps?

We’ll see.

One thing is for certain, Apple does not equal Open.

The Apple iPhone has been garnering the interests of the Department of Justice (DoJ) and the Federal Trade Commission (FTC).  But not in the way one might think.  Oh no.  Not at all.

Apple’s recent ban on coding languages for iPhone apps has got the feds “locked in negotiations” over who gets to investigate Apple for its anti-competitive practices, according to The New York Post.  Yes, that’s right, antitrust regulations just may soon be bopping Apple on the nose for being naughty.

For those of you not following the drama, Apple (and purportedly CEO Steve Jobs) have something very much against Flash.  So much so that Apple has imposed regulations into their new software development kit (SDK) that “only Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs.“  Thereby preventing any real interpreted language such as Java, Python,0r Flash from being used.  Or for that matter any intermediary libraries such as the likes of Qt meant to make multi-platform development possible.  In fact, even cross-platform development tools like Appcelerator’s Titanium, PhoneGap, and Unity 3D may not pass Apple’s muster, as they allow programming in languages other than Apple’s approved list, even if they do translate into Objective C before compiling.  It doesn’t matter if the end result of the app is native execution, and possibly doesn’t matter if the result is native compiling.  So long as the original code isn’t in an Apple-approved language, the app is banned according to Apple’s wording!

Needless to say, Apple is going to great lengths here to make their iPods, iPhones, and iPads closed rather than open.  And seems to have a particular grudge specifically with Adobe Flash.  Something which may have just gone a step too far for the regulatory agencies to allow to continue unchecked.  Or may not.  An investigation doesn’t necessarily mean that Apple has done anything wrong.  It could be found that Apple is behaving within the law.

But for Apple to have even pushed that envelope that far, Apple, a company long accusing others of doing these wrongs as a means of promoting their rightness, is a very bad thing.

Those of you web developers who have been using Google’s Gears API are in for some bad news, you’re going to have to shift your paradigm to something else.  Google is dropping Gears in favor of HTML5 API.

“We will continue to support Gears until such a migration is more feasible, but this support will be necessarily constrained in scope. We will not be investing resources in active development of new features,” says Ian Fette on Google’s Gears blog.

I guess that even the mighty Google can’t really afford to reinvent the wheel in multiple simultaneous ways.  Not really a surprise, that.  Still, I do rather feel bad for anyone who has heavily based their code on Gears.  Looks like it’s time to research your best feasible transition.