Stuxnet, the most advanced computer virus ever discovered (by a long way), generally believed to be the first sophisticated example of a virus being used as an international military weapon, just got an upgrade. Most likely from its original authors.
At least, according to Symantec's analysis lab where a recently found version has been dissected on the operating table, it looks like the versions found in the wild "in Europe" were targeted test runs of a new version that was partly recompiled from the original source code which has so far remained secret.
The new version carries a different payload to the original Stuxnet which, it is generally believed, was intended to shut down or disrupt Iranian nuclear facilities. In fact the new version's actual payload is pluggable. Modules can be loaded dynamically from a command and control server located in India.
Duqu, as the new version is called, can read and write files, execute programs, capture keyboard input (to collect passwords) and generally open back doors for later use by the unknown attackers.
Check out the great article on this by Read Write Web and for a quick recap on the original Stuxnet, check this nicely produced - if creepy - video by Hungry Beast in Australia:
19 October 2011
09 October 2011
Why Programming is Hard
Programming is not hard because computers are fussy. Programming is hard, but not for that reason.
There are plenty of pesky surface details in managing programming projects and programmers regularly find themselves burdened with managing tools and configuration details. More so when using Maven (Zing!).
But this is just work. Annoying repetitive work. It's not what makes programming hard.
In fact, programming is hard because there are so few limits to what you can do.
Certainly there are limits to computability, and there are famous problems and algorithms that define the state of the art in computer science, but for many programmers, knowing about these limits is enough to prevent them from pushing up against the hardness of these limits on a regular basis.
Programming is hard because the only limit is our own mental capability. It's always going to appear to be hard. It doesn't matter how smart you are.
If programming is not hard, then you're doing it wrong. Your brain is not being fully utilised? You are being limited by your tools and you need to replace them.
Any time spent dealing with repetitive details, remembering lots of things or even managing huge amounts of code, this time waste generally can be eliminated with more programming! This assumes you're in a postion to change the system enough and perhaps this is where practical project tradeoffs impose. And perhaps "the business" isn't interested in funding improvements to the open source build tool, or switching from Java to Scala. (Double Zing!) But those are not programming problems.
For me, because software is so soft, the goals can be altered subtly, continuously, destructively. Especially when ill-defined. The hardest thing generally comes down to dealing with the confusion of some form of not being clear what I'm trying to do. Unravelling the "is it this or is it that" trail of mental plans that led to the curent state. When this happens in the large, a software project is almost certain to fail.
But maybe that's just me. Do you think programming is not hard? Do you think it's hard for a different reason?
There are plenty of pesky surface details in managing programming projects and programmers regularly find themselves burdened with managing tools and configuration details. More so when using Maven (Zing!).
But this is just work. Annoying repetitive work. It's not what makes programming hard.
In fact, programming is hard because there are so few limits to what you can do.
Certainly there are limits to computability, and there are famous problems and algorithms that define the state of the art in computer science, but for many programmers, knowing about these limits is enough to prevent them from pushing up against the hardness of these limits on a regular basis.
Programming is hard because the only limit is our own mental capability. It's always going to appear to be hard. It doesn't matter how smart you are.
If programming is not hard, then you're doing it wrong. Your brain is not being fully utilised? You are being limited by your tools and you need to replace them.
Any time spent dealing with repetitive details, remembering lots of things or even managing huge amounts of code, this time waste generally can be eliminated with more programming! This assumes you're in a postion to change the system enough and perhaps this is where practical project tradeoffs impose. And perhaps "the business" isn't interested in funding improvements to the open source build tool, or switching from Java to Scala. (Double Zing!) But those are not programming problems.
For me, because software is so soft, the goals can be altered subtly, continuously, destructively. Especially when ill-defined. The hardest thing generally comes down to dealing with the confusion of some form of not being clear what I'm trying to do. Unravelling the "is it this or is it that" trail of mental plans that led to the curent state. When this happens in the large, a software project is almost certain to fail.
But maybe that's just me. Do you think programming is not hard? Do you think it's hard for a different reason?
30 September 2011
32 Bit 64 Bit - All up in your Bitness
Here's one for the logophiles. English usage nerds. I'm coming out as a bit of a language nerd officially, today, so consider yourself warned.
In film they talk of footage. In transport, haulage. Then there are words like passage, patronage and of course cleavage. At school my friends and I would regularly put "-age" after words. "Foodage?" would mean "are you hungry?". "Skateage" was time spent skateboarding.
So what is it when you want to refer to how many bits something is?
You know your latest laptop is 64 bits and your last one was 32 bits. You know about the 16 bit retro video games like Sonic the Hedgehog and maybe even the "8 bit era" of the Commodore 64. So what do call that ... bitness?
I've heard it called bitness, and tweeted about it a while ago and got some interesting alternatives:
In film they talk of footage. In transport, haulage. Then there are words like passage, patronage and of course cleavage. At school my friends and I would regularly put "-age" after words. "Foodage?" would mean "are you hungry?". "Skateage" was time spent skateboarding.
So what is it when you want to refer to how many bits something is?
You know your latest laptop is 64 bits and your last one was 32 bits. You know about the 16 bit retro video games like Sonic the Hedgehog and maybe even the "8 bit era" of the Commodore 64. So what do call that ... bitness?
I've heard it called bitness, and tweeted about it a while ago and got some interesting alternatives:
- bitness
- bittage
- bittitude
- bitality
- bitosity
- bitch
I guess the last one is a little challenging, linguistically. Maybe German?
Of course I had lots of replies to my tweet saying well you're talking about "word length" or "machine architecture" or other term specific to the usage. Well what if I'm talking about sound samples? "Is that a 16 bit sample or a 32 bit one?". Or colour space in digital imagery? Is that 24 bit colour? Ignoring bittitude is just like saying you can't call it footage, you have to call it film length.
We need to agree on a word that covers bitness and I think I'm coming down on the side of bittage.
Of course this is a question of crucial importance to the world (not - but I did warn you).
24 August 2011
Last Minute Usability
Usability, like scalability and security cannot be added to a finished product any more than flavour can be added to a finished meal.
![]()
delicious photo by Shutter Ferret
delicious photo by Shutter Ferret
19 April 2011
This is NOT the 80:20 Rule You Are Looking For
The 80:20 rule is based on the assumption that there is (often) an 80% (ish) subset of the realised value for a project that only costs 20% of the resources (e.g time) to complete. The rule, actually the Pareto Principle popularised by Richard Koch and others, like all rules of thumb, can be applied incorrectly.
It's not a license for doing things half-arsed.
07 December 2010
Guy Steele Disassembles 40 Year Old Punchcard
Just a quick note to let all of you know who are not currently at the YOW! 2010 conference, some of the fun that you're missing out on.
Firstly it must be said that this is a world-class conference. The calibre of speakers is amazing. Dave Thomas and his team have done an incredible job of drawing this talent to Australia for this meeting of minds. I'll be posting more about this stuff later, but for now, here's a teaser photo from one of my favourite sessions, Guy Steele's "How to Think about Parallel Programming--Not!
In this photo, Guy is disassembling his own 40 year old self-modifing code, starting with a punch card and an old manual (which he admitted to still owning). He demonstrates his deserved bare-metal hacker street cred. Then half-way through the talk he shifts gears into real parallel programming in Fortress. I was quite exhausted after that one!
Firstly it must be said that this is a world-class conference. The calibre of speakers is amazing. Dave Thomas and his team have done an incredible job of drawing this talent to Australia for this meeting of minds. I'll be posting more about this stuff later, but for now, here's a teaser photo from one of my favourite sessions, Guy Steele's "How to Think about Parallel Programming--Not!
In this photo, Guy is disassembling his own 40 year old self-modifing code, starting with a punch card and an old manual (which he admitted to still owning). He demonstrates his deserved bare-metal hacker street cred. Then half-way through the talk he shifts gears into real parallel programming in Fortress. I was quite exhausted after that one!
24 August 2010
23 August 2010
Next Android OS Codename: Apple Pie
 |
| cc photo by http://www.flickr.com/photos/mattmendoza |
OMG Google has to do this.
With the Android OS versions getting code names like cupcake, éclair and froyo (which is, evidently, a word), the dessert namespace provides an opportunity too good to miss. Apple Pie. OM NOM NOM.
Of course the logo should be a white stylised piece of apple pie with one bite out of it. Or perhaps a rainbow version?
People, Google fanboys and Apple haters mostly, desperately want Android to DUHSHTROY iPhone in the market. Personally I don't think this is very likely. I know there are a lot of Android devices out now - more than iPhone I hear - but the fragmentation is really starting to happen. Just like MSX.
The code name of Apple Pie would trump the Eclipse Foundation's latest IDE version naming stunt, Helios, Ancient Greek for Sun, aka their competitor recently bought by Oracle who is now suing.. Google. Keeping up?
20 August 2010
Why Bookshops Always Put Computer Books With Business
It's near-universal. Especially for those bookshops with large self-help or mysticism and occult sections and no science section. Computer books are put (and often intermingled with) business books.
Why?
To me it's like always putting cycling with business. Or painting.
Yes computers are used heavily in business, but they're used just as heavily in music or movies or writing.
When I look for programming books, sometimes I'm interested in the topics that combine businesses (or the needs of an organisation) with programming - generally topics like how to translate the needs of project sponsors into deliverable systems. But way more often than that I'm interested in topics that concern the creation of software using specific techniques, paradigms, or languages and frameworks.
I like programming. I would do it more on the weekends if I had time. I don't think it has anything in common with business but it seems that many non-technically minded people assume that the only reason someone would want to do programming is for business purposes.
Well plenty of people do it for fun. Just like cycling or painting.
05 July 2010
Apple: I Was Wrong, Here's Your $200 Back
Previously on Chris Mountford's blog...
Genius: "Oh um ya that battery that split open like a stepped-on-banana.. that's expected behaviour"
Me: "You're kidding me? Should I expecting all other Apple products to do this?
The latest is, thanks to Mr Anonymous, Paul M and legion others like them, is that I have been refunded my $200 because, as a reasonable person would assume, the extended warranty DOES cover such explosive situations.
Genius: "Oh um ya that battery that split open like a stepped-on-banana.. that's expected behaviour"
Me: "You're kidding me? Should I expecting all other Apple products to do this?
The latest is, thanks to Mr Anonymous, Paul M and legion others like them, is that I have been refunded my $200 because, as a reasonable person would assume, the extended warranty DOES cover such explosive situations.
Subscribe to:
Posts (Atom)