In this case, the tutorial appears the first time any new user logs in (be that domain or local). Need to find out how to kill it, actually, via GPO, or it'll drive me batty.

In this case, would it not be that Le Monde is going to start charging the newsagent (news stand) based on the number of people who read the headlines, then either buy something different or walk away?

My first thought when I read the article was "just sell it as a novelty product" - green and yellow honey in some sort of twin pack might go down well in sports-mad Australia, for example. But those pictures are much, much more disturbing than I expected, and I'm not sure I could get past the colour after all. Maybe kids would love the idea of funky-coloured honey though (they like tomato sauce to be green FFS - kids are weird).

For me it's not the "hard and catastrophic" failures that are a problem - it's the subtle ones. For example a recent customer environment - DNS lookup for a particular server returned the wrong IP. It worked perfectly, and fast, except that the data was wrong. It took nearly a week of debugging firewalls, routing tables, services and app configuration to figure it out - and the problem was actually caused by OpenDNS and its filtering.

When you look at "64.27.80.4" and compare it to "67.215.2.41" the differences are obvious. Not so when you're trying to compare "6732:87fb:87fa:12a9::54d8" with "6732:87fb:87fa:72a9::54d8" and work out why things are failing.

Darn, I was with you all the way until we got to your last assumption:

Intel? At the TSA? Not going to happen (aka "Beam me up Scotty, there's no intelligent life down here").

Absolutely - I see SlashBI and I think "great idea, let's slash our business intelligence [further] by getting the MBAs to read this site". I doubt that that's the reaction for which the MBA crowd aimed, however.

This is the first reply I've seen that has the right idea. I'd take it a step further though, and suggest that you should decide how you want your staff to look and use that to guide your own choice of clothes. If you're happy with them in jeans and t-shirts, go slacks or "nice" skirt and matching top, and make it clear if they ask, that you prefer (need) them to dress in jeans and t-shirt or better "just in case". Remember your customers may not be outside your organisation, and internal people will judge your staff's clothing just as much as will an outside customer.

Or at least in Sydney, pretty much every cab has recording devices "for the safety of driver and passenger". Most appeared after the well publicised bashing of taxi drivers. Thanks numpties for ruining privacy for the rest of us.

I'm onboard with the quote, but let's make Marvin's quote accurate: "Where's the kaboom? There was supposed to be an earth -shattering kaboom!"

Uh, no, no it can't, not no way no how. And it doesn't necessarily perform better for SQL either. A 2 disk RAID 1 can handle one of the two disks dying. A RAID 5 of ANY size can handle one of the n disks dying. If you're thinking of RAID 6 (HP called it RAID ADG for ages) then yes that can handle 2 disk failures. So can RAID 10 for a subset of cases.

And in either case I doubt POS for a restaurant is taxing the server - I recall Dominos stores in Australia running a simple SATA mirror set on their in-store servers for hundreds of orders each night. The biggest load it ever had was reporting (end of day etc).

As for my recommendation - two desktops (relatively new) with SQL Server mirroring and backup to disk (replicate the backups). Having the data and logs backed up gives you protection against "delete database" and Bobby Tables, among other things, which you will not get with a straight replica. Failover should be as simple as an icon on the desktop (that runs the appropriate script). Not automatic, but cheaper than having a third PC with SQL Express (or Workgroup, or whatever they're calling it nowadays) for a witness server. Less to go wrong too.

Desktop support isn't just about the hardware and OS. It is also about "how do I do X" and "I can't access the Internet". Both of which require hands on help, if not always, certainly often. Plus as others have said, it is a poorly disguised marketing effort by Gartner, so ignore it .. SITREP normal for now.

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.