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 "184.108.40.206" and compare it to "220.127.116.11" 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.
Someone somewhere must have gotten some intel about this vector.
Intel? At the TSA? Not going to happen (aka "Beam me up Scotty, there's no intelligent life down here").
I recommended RAID 5 because it can tolerate two drive failures if you give it all five, and I have seen two drives fail at once. It also performs better for SQL, not that it really matters in this case.
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.
Consumer level routers don't need RADIUS or 802.1x.
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.
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:
Exceptions! Catch them please! No one is immune to this, granted. However the forgot to catch an exception for Visual Studio coders is quite higher than say the guys that write C++ or Java and use Eclipse.
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.
Adding features does not necessarily increase functionality -- it just makes the manuals thicker.