9 posts • joined 5 Jun 2012
Not just a security update
In keeping with past practices, this is not just a security update for Java from Oracle. No, like many previous releases of Java, there are also major functionality changes included, that once again mean that enterprises can't just push the security updates out, because the bundled non-security changes break stuff. (e.g. Java 7u51 requires that every app has to be recompiled with a new manifest and digitally signed).
For enterprises that have inventories of tens or hundreds of Java applications, cost aside, the requisite remediation that has to happen BEFORE the latest security patches can be deployed is simply not feasible in a timeframe that would avoid lengthy exposure to all the nasty malware that we know is actively targeting Java. The arrogance on the part of Oracle is stunning - they are still ten years behind companies like Microsoft on the patching front.
Will make an awesome password cracker or Bitcoin miner with all those GPU's humming away...
Pot, kettle, black?
It must be really frustrating for Google to find out that their monopoly on our personal information has been broken.
Re: Comments slow my code down - when comments become code
Oh, and the "rule" for a long time at another place I briefly worked was that comments had to have jump instructions around them - to avoid programs being slowed when "processing" them! Even batch files were not spared - every comment had to be preceded by a GOTO statement jumping to a named label:
REM * This is a comment
Comments slow my code down
I once worked with a smart arse whose rationale for not putting any comments in any code was that they would slow down execution of his apps. Now, just to be clear, we're not talking about interpreted or JIT-compiled code here. Later after wearing him down some, his argument reduced to the comments slowing down interpreted code, so we organised a little test in the office with HEAVILY commented vs uncommented version of a script of his, and ran benchmarks on them - we were unable to measure any difference between them...
Oh dear, there goes someone's bonus...
Three years ago, the corporate IT environment in which I work was in dire straits. IE6 was still deployed on 90% of the desktop fleet, the end of support for WinXP/IE6 was looming, and the hundreds of developers and partners refused to remediate their IE6 apps because no funding was forthcoming,. The problem was so tough that no-one knew where to start. Then Chrome Frame came along, everything was fixed overnight. IE6 did not have to upgraded after all, no-one had to fix any code, nothing had to be retested, no end users had to be retrained to use a different browser, and a monkey could be taught to map individual sites to render in Chrome Frame. Investment could be shelved and some very big bonuses paid out to the forward-thinking architects responsible for devising this brilliant strategy.
Imagine the consternation this week when some recently-promoted architects found out that Chrome Frame won't be around for the foreseeable future.
Wait until the consumers find out after their upgrade that some of the toys they've got used to (Media Center) are now a paid-for upgrade. Reminds me of the punters that haggle over the price of their new tv, then get stung when they buy a $50 HDMI cable to go with it...
Re: Microsoft didn't break MD5
...except that it seems someone at Ms forgot to follow their own advice from way back in 2008:
Microsoft didn't break MD5
It's called a "collision attack" and comes about because of vunerabilties in the long-troubled MD5 algorithm (see http://www.win.tue.nl/hashclash/rogue-ca/). Mostly the fault lies with certificate authorities who continue to use this weak algorithm.
SHA1 is starting to look vulnerable too now - are we going to find a way to blame that on Microsoft too?
Grow up everyone - it's time to realise that this is an industry problem, not a vendor problem...