Oh shut up - taking a pass on DRM is not "pick your battles carefully". Flash and Silverlight are dying on their own because they don't run, or run barely, on the current generation of smart phones, tablets, and ... wait for it ... smart TV's. The content distributors desperately need standardisation because supporting hundreds of device types and dozens of plug-in technologies is a pain in the neck. The problem is they've chosen to outsource the problem by making browser vendors write the proprietary DRM plug-ins for them. Instead of simply adopting the existing specifications for Internet video formats and protocols. Everything they want to do can already be done with AVI/MP4/etc together with HTTP/RTP and a "video" tag in HTML. Everything that is except spy on users and take away people's ability to enjoy the content on a whim. If we resist DRM, they'll either have to adopt open standards or they'll have no business model at all.

Any headline where the US is demanding that some other country stop doing something can be simply answered with "You First Sparky!".

Speaks someone who has no idea where their food comes from. Hint: agriculture.

Here's one simple example: Every morning the cows come in around dawn to be milked. Several hours later the milk tanker arrives to collect the milk and take it to the bottlers to get it ready to put on the trucks to go to the supermarket for you to buy tomorrow.

The cows will come in a little later in winter. Which pushes the schedules for the tanker drivers and bottlers back by an hour. Now the bottlers who used to work 9-5 are working 10-6. Also shifted are the truck drivers going to the supermarkets. And the stockists in the stores. And so on.

Do you really think it is a good idea to force millions and millions of low-paid truck drivers, milk bottlers, and cheese churners to work idiotic shifts and see their families even less just so that you can avoid having to change your office-worker watch twice a year? There are more people in society than you post-industrial types.

It's not the title, it's the attitude. If you write code the way a civil engineer designs bridges and or an electrical engineer builds circuits, you will build crap.

When building a bridge to take a 10 ton load, you better use 15 ton beams just in case one is under spec. When building a circuit to switch at 10 MHz, use components designed for 12 MHz just in case one is under spec. It's called "tolerances" and is the underpinning of all engineering, and is a great idea for those fields where once it is built the requirements generally stop changing.

Except in software engineering. Tolerances in software are called "fudge factors" or "heuristics", and they always result in unmaintainable spaghetti as requirements constantly change over time.

I use the term "Software Developer" for myself because I refuse to "engineer" software; i.e. build crap. My most recent contract involved fixing problems in embedded systems code written by an EE major. Total nightmare - no unit tests, no code comments to speak off, mysterious algorithms with no explanation as to where they came from, references to "see datasheet" for the component that was used three board revisions ago but not any more, and so on. The circuit? An absolutely beautiful example of balancing requirements and managing tolerances. But the code to run the circuit was rubbish that would get stamped "go back and do that again" by the code reviewers in any software development shop.

The ironic thing is that the term "Software Engineer" was coined to give developers the air of professionalism. Perhaps the engineers could learn something about professionalism from the developers instead? Like how to design a system that won't fail the minute the requirements change.

A whole car may be silly, but the thing about cars is they need repairs. I scraped the side of my car against a concrete pole in a carpark a few years back. Easy enough for the panel beaters to bang out the dings and repaint the doors ... except for a scratched-up door handle. They would have had to send away to Korea at great expense to get a completely new injection moulded handle. For now I'm putting up with the scratches. But imagine if my panel beater could just pop the design into a 3D printer and make me a new one on the spot? That's what scares the crap out of traditional car manufacturers ... that they can no longer rip you off for replacement parts.

Lua, Python, PHP? All scripting languages, useful for their purpose of quick one-off glue tasks, but not anywhere close to "real programming". Call me when you can write a 300,000 line C++ or Java monster on the thing without ending up with debilitating eye or wrist strain injuries.

Curiosity is doing more science per second ON ANOTHER PLANET just sitting there checking its systems than the entire human race has achieved to date. Decades from now, scientists will still be pulling interesting information out of the data that was missed on the first pass. This is a genuine GOOD for the human race as a whole - don't screw it up to do the equivalent of spray-painting "l33tme w0z ere" on the side. Unless you're willing to pay the cost to send up a replacement robot, find something else to amuse yourself with.

Even if we were to assume that cell phones put out sufficient radiation to heat up the water molecules in the brain enough to be noticeable, it still pales into insignificance compared to the heating your brain receives when you have a hot shower and wash your hair. Or walk around without a hat on a summers day. If low-level heat from everyday sources caused cancer then the human race would have gone extinct in 50,000BCE when we invented fire.

Porn problem? What about Wikipedia's bomb problem? Enough information about chemistry and physics to build your own homemade bomb. Depending upon your budget, everything from firecrackers and pipe bombs to nuclear weapons. What about Wikipedia's computer security problem? Blow by blow descriptions of common computer vulnerabilities and how they can be exploited.

And so on.

We've been down this road before with the debates over the Anarchist's Cookbook and hacking manuals. Banning, or labelling, or whatever serves no purpose except to enable government censors to make up excuses to block other information. And look - you gave them a nice little filtering system to help them do exactly that!

Of course Wikipedia needs to tread softly - they are the repository of the world's knowledge and anything that reduces access to knowledge is against its charter. Make the descriptions of various porn acts more clinical and less explicit, perhaps. But that won't stop the "think of the children!" crowd.

And how many milliseconds until this happens:

A new law was passed today by both houses of Congress making it illegal for pharmacies to sell over the counter HIV tests. The author of the bill, congressman John Q. Religinut, Jr (R) welcomed the passage of the law saying "Today we have taken a stand against promiscuity and the homosexual agenda".

And then come back and find the damn disk is still waiting at the "Select English or 40 Languages You Don't Speak" screen waiting for you to hit the OK button. Seriously, is it really so hard to detect the language I've already set on my Blu-Ray player and use that by default?

In any case, if "insert disk, go do something else, then watch movie" becomes a problem, I'm sure the studios will "fix" that by adding a EULA click to the Copyright warning screens.

The contents of any business person's carry-on bag looks like that on an X-ray scanner. Phone, MP3 layer, USB cables, laptop and power brick, bent paper clip to reset dodgy devices, RSA security key for remote VPN access, prototype PCB for the embedded device my company is working on, etc. By the time that tangle of wires gets to the airport, it WILL look like a horrid science experiment that is a pound of C4 away from blowing up. Yet such tangles regularly pass through security with a brief 2 second eyeball from a bored TSA grunt. The only difference here is that the tangle was left behind on the plane.

Heck, OLD people are not used to paying for music. I've had access to thousands of songs for near zero cost my entire life. It's called a radio. And I've probably spent a few hundred dollars total my entire life on products advertised on the radio, of which only a tiny fraction in the millicents range made it to the artists that created all that music. I have a few CD's, but nothing close to the amount I've consumed via radio over the years while paying peanuts. Music has always been cheap, and the record industry has always tried to invent ways to pretend that it isn't. There may be a future in creating custom listening mixes and radio-like streams. But $0.99 per song? Get real. It would be a rip-off at $0.01 per song.

If you need a compiler with special optimization options to make your code run fast, then either your algorithm or your data structure is wrong. Implicitly-parallel SIMD problems are a notable exception - same operation on massive amount of data. Everything else is PEBKAC.

Happy birthday gcc - making me think more carefully and write better code for 25 years!

... but instead I was thanklessly modifying shaders and texture formats to work on different GPUs,

OpenGL has become a joke under Khronos. More and more of the work needed to render scenes is pushed back onto the application developer. Once upon a time you could specify the material, texture, and light parameters and IT WOULD JUST FIGURE IT OUT! The responsibility for making it run fast was up to the OpenGL implementer, not the application writer. Now you cannot draw a single triangle without a month's worth of effort to implement matrix math, texture uploading, and material lighting from first principles. And then do it all over again on the next device because the stupid chipset vendor decided that they couldn't be bothered making simple color interpolation work fast (I'm looking at you ImgTech).

The problem is not handset fragmentation. The problem is that the OpenGL API provides no guarantees about what will actually work and work well. It's all thrown back onto the application and the chipset vendors can then brush off bugs in their design with "our examples work great - obviously you don't know how to write shaders".

It's time the application (not chipset) developer community smacked Khronos upside the head and made them specify a USEFUL rendering API that guarantees good performance for application-level tasks, and decertify chipset vendors who are too lazy to do their damn jobs.