I pretty much agree with everything you said, other than this.

So if you are a tech geek, and want to learn how to configure and manage certificate-based access, or centralised RADIUS, you need to spend 10x the average on a Cisco/Juniper type solution? Nah, leave it in. It hurts no-one to have other secure options there as long as the default state of the router (hold reset and power on) is WPA2+AES with a random password engraved or stamped on the bottom of the router.

Don't worry about it too much - my 33:2 sample here at work drags our two sample average closer to the 10:1 you chose. And yes, I chose 10:1 (seriously, no higher options either way?). And the 2:0 sample at home is infinitely bigger than the 10:1 ratio anyway.

Well by that argument, I think you're saying the music Tenenbaum distributed is worth approximately double that of Beatles music. If MJ paid $47.5M for 4000 tracks, or 11,875 each on average, then that's darn near half of the per-track infringement damages - and it's not like he suddenly owns the right to distribute either. So I'm not convinced that saying "the tracks Mr Tenenbaum distributed are valued at approximately double a comparable Beatles track" is necessarily reasonable.

1. Agreed

2 - not sure it is that big an issue, but I don't believe you're wrong.

3 - not sure what you're saying here, this is about teaching people to use the code management tools available to them, not the IDE.

4 - are you contradicting yourself - you say VS coders break things up and Coders don't?

5 - isn't just VS coders.

I'd specifically like to call out statement 6 though:

I think you're conflating two different approaches here. On the class library side of things, I'm strongly against catching all exceptions. The only exceptions a library should catch - and this is one of many opinions I freely admit - are those where the cause of the exception is totally and completely within the method call. That means any method using external data, externally configured data sources, parameters etc should not hide the exception but allow it to bubble back to the calling app. The app can then decide what to do (example - a misconfigured database connection string).

A program/application, on the other hand, should almost never show a user an unhandled exception. Not that I'm great at that either but still, that's my viewpoint. Again an exception - things like exceptions in an exception handler might be good exceptions to the "don't show exceptions" mantra.

Australian ISP BigPond changes name to SmallPuddle ...

On the contrary, the user has NO control over app permissions, by default. The app author sets what he/she wants, and the user has the choice of accepting it or finding an alternative. No justification, no ability to say "well I want this useful SSH app but I don't want it reading my contacts, so I'll deny that permission". Yes, there are firewall apps (the permissions are in the OS, why do I need an APP to enforce OS permissions?) and for rooted devices, apps that can tweak permissions. But the default is horribly, terribly broken because most of the power is in the hands of the developers, NOT the users.

That "Minding your Microsoft Manners" thing might be a little over the top - but compare it to that favourite analogy, the car industry. Would BMW be happy for their partners (dealers) to show up to a meeting in a Mercedes? Would you think maybe, just maybe, talking up the newest Chev to a Ford manager is a good plan? This is basic stuff - if you're working with a company to sell their stuff, you talk up their stuff not the competition?

OTOH, if you were being sarcastic, then as you were.

Indeed - the biggest state (certainly at the time, and I think still) is NSW with more than 1.2M students across primary, secondary and TAFE (Technical and Further Education - sort of a mix of upper secondary, trade and university-level students). In about 2001 the education department created a single hosted environment for all students so that everyone had access to online chats (i.e. classes with guests, Q&A etc), web hosting for things like assignments, restricted web browsing, email etc; with the plan that everyone would have a base level of access.

And you know what? It wasn't too bad (for the time and level of technology we had - lots of weird constraints came up over the course of the project, some solvable, some not). It has been much improved, since.

So you're comparing "type email, click send" with "type email, select all, exclude the signature block, cut the message (not copy - or they'll dupe the content), open a new application, click a button, enter the passphrase, switch back to the message, paste in the signed text, click send" and you don't understand why a user might think it's "too hard"?

OK, OK, that's fine. Here's a suggestion. Make it easy for the user and they'll be more likely to do it.

Write an extension to $MUA that puts an extra button in the toolbar for "Sign and Send" (or replace/extend the existing button). Hook Ctrl+S, Ctrl+Enter (or whatever keys $MUA uses to send email). When the message is about to be sent, pop the passphrase dialog up and let the user enter their password (have three buttons: Sign and Send, Send Unsafely and Don't Send).

Yes, you'll have to do more work. You might even have to fire up Visual Studio to do it rather than hacking in vi. But the chances of success will be greatly improved if the user doesn't have half a dozen manual steps to go through. (Thinking about it briefly, you should be smart about the dialog only showing up when messages go to a particular address, or set of addresses, which would also greatly improve usability).

There's a few potential problems with that comment.

1. 1. People are, as a general rule, stupid. Yes, I include myself - you can't know everything about everything, no matter how much you try. It therefore stands to reason that if you know lots about one topic, you might not know lots about others. (If you know everything about everything, and are GOOD at everything, you're lying or you're the most intelligent and capable person on the planet by several orders of magnitude).
2. 2. 90% of the population won't give a crap about learning it, 90% of the remainder won't be good at it and 90% of what's left won't remember it in a true emergency. (Yes, I agree 90% of statistics are made up, I'm illuminating the problem not giving data). The other 0.1% will avoid the accident. Are you willing to believe you're 1 in 1000 every time you drive - and if you are, are you also lucky enough never to meet any of the other 999?
3. 3. Modern ABS handles it OK, but older systems can't handle the driver reducing brake pressure and either stop working (lockup) or continue working even if the tyres would grip. Both of THOSE scenarios cause longer stopping distances and potentially less steering control than ABS alone.

Interesting to note, I've been told by numerous driving instructors and amateur racers (I used to be a poor amateur and don't know any pros) - they are often no better at stopping than simply stomping on the ABS in an emergency.

Let the ABS do its job. Learn how to handle having ABS, please. Learn to threshold brake by all means. And understand that when the idiot in the ute pulls out 15m (45ft) in front of you while you're driving along at 35mph (55kph) - there's a damn good chance you'll forget everything and slam your foot on the brake. When you do, be glad you have ABS.