In the current arrangement, the parallel CA hierarchy allows you to provide a (theoretically) verifiable connection despite your registrar or DNS provider being perhaps less reputable than you'd like. For an attacker to silently redirect your SSL traffic, he has to compromise at least two external entities--your CA & DNS host/registrar or your CA and somebody in a position to MITM your traffic (obviously a local compromise gets him everything, but this is within your direct control). While I'm no fan of the CA model, the stuff pulled by companies in the DNS market (registrars and hosts both) make the CA's look positively responsible, and handing them all the keys necessary to silently redirect traffic makes me uneasy.

It seems that by suggesting these functions be consolidated into DNS, you're effectively saying that by consolidating two untrustworthy parties into one untrustworthy party, you'll be more secure. I'm pretty sure I don't agree with that, but I'm willing to listen. How do you address such criticism?

This is an interesting approach, especially across hosts in a cluster. Is it safe to assume you expect your hosts and interconnect to be very reliable?

I'm curious about the methods you use to mitigate the problems that would seem to result if you clone VM 1 from Host A onto VM's 2-10 on hosts B-E, and Host A dies before the entirety of VM 1's memory is copied elsewhere. Can you shed any light on this?

While this was true in ESX 2.x (which introduced virtual SMP), this is no longer the case. This limitation was largely removed with the introduction of relaxed coscheduling in ESX 3.x (2006-ish). More information is available in this document.

It should be cooked until the fats have just liquefied, for optimal juiciness and flavor. In my experience, most good restaurants call this "rare". At most other restaurants, it's a complete crapshoot, which is why I typically prefer to cook steaks at home.

Start with high heat to sear, move to lower heat to finish if necessary, and don't forget to let it rest before you serve/eat it. Rubs are an exercise left to the reader, but kosher salt & fresh-cracked pepper make a good place to start.

Enjoy!

That's not what he's saying at all. He's advising you to not put too many eggs in one basket. I'd be more inclined to trust a company that gives such advice, because it's good advice.

If you have all your data and DNS stuff locked up with one company and you want to switch to a new provider, you're at their mercy. If they go under or have a management change that inspires them to be less responsive, you're screwed.

If you use one company as registrar, another to host your DNS, another to host your live site, and another to host your backup, more people have to screw up before you've got an irretrievable mess. If the ones hosting your live site screw up, you can replace them with somebody else, repoint the DNS with your DNS provider, and restore the data from the third-party backup provider. Good luck doing this if you put all your eggs in one basket because the provider assured you they were competent and there was no need to hire anybody else.

Replaying this scenario with screwups on the parts of other parties in this arrangement is left as an exercise for the reader. Alternately, you could just place all your business with the same company and wait awhile. Eventually you'll be pulling your hair out one night saying to a coworker "If only we had placed [blah] piece of this with another provider, we could have had the site back up by now..".

I remember there being some small parks around Moscow, but I don't remember any being very large or particularly noteworthy. One of the things there seems to be no shortage of in Russia is labor--you'll find humans performing tasks there that seem either completely unnecessary or like they should've been automated away long ago. This extends to park maintenance, as well. I was amazed at how many people it seemed to take to water the flowers in the park outside the Kremlin the last time I was there. I'd be surprised if they worried about it taking a little more work to get the flowers to grow due to lack of insulating snowcover over the winter.

From the perspective of a modern-day westerner, russians seem to have an interesting relationship with nature. When they build cities, they don't play around. They pile in the industry, and the cities are typically dirty and hazy from exhaust of various kinds, dirt, etc. The parts of Russia I've seen outside of Moscow & St Petersburg look a lot like the photos I've seen of Soviet-era cities, aside from the gradual infiltration of english words in signs over the past several years. In contrast, it seems many families--not just the rich--have summer cottages on the outskirts of the cities which are teeming with gardens and plants and anything green or edible, and are quite pretty (ignoring the smokestacks billowing in the background). It's like they have everything neatly compartmentalized.

I can also see why they seem more willing than we are to screw around with the environment. They don't really have suburbs and sprawl in the same way we do in the US. As you ride the train through the countryside, you see a city with some villages clustered around it, then hours upon hours of solid trees and grasses, then another city with some villages around it, then more hours of trees and grasses. It's an enormous country, and it seems largely unpopulated by humans, aside from those small clusters around the cities you see every so often. It's easy to not worry much about nature when there's so much of it around.

You think those famous russian authors all wrote depressing novels by coincidence? Personally, I loved St Petersburg in February, but I'm a little odd that way. I've spent an aggregate of about six weeks in Russia over the past couple years, and while I find the culture fascinating and the people wonderful, I'm not sure I could handle living in any of their cities for an extended period of time. There's a possible exception in St Petersburg, but that one's too european to really be russian, anyway. Russia is definitely a cool place to visit, though--I highly recommend it if you get the chance.

It's more than that. There are more moving and breakable parts between you and a hosted provider than between you and an internal service, which changes the math a bit.

Some of the single points of failure are shared between both approaches too, so they're a wash for a small implementation. If you're a small company and your non-redundant core switch fails, your email is down either way, because you can't get to your email server or to your hosted provider, no matter how redundant your provider is. There are various components for which this is true, which helps to mitigate the benefit of a hosted service where your mail server is replaced by a massively redundant cluster.

You also have additional dependencies. If you're a small business with a single T1 to the internet, let's say, and the telecom bunker outside your building catches fire and you lose internet access, you've got problems. With a local email service, internal mail works, but you can't send email to or receive email from external users (let's pretend you don't have an offsite secondary MX or an outbound mail spool where this stuff queues, mostly invisibly to users). For organizations that are hugely dependent on internal email, that's quite a bit better than having no access to your (hosted) email at all.

Additionally, you get concerns about "If we outsource this today and we have problems in 2 years, will we still have somebody here who can design/build/find a better solution, or will it cost us a fortune in consultants if we let the in-house expertise lapse?".

You also have support issues. Google specifically is well-known for only doing things that can be automated (and doing them well, mind you). Support isn't always one of those things, and small companies are well-acquainted with getting the shaft from vendors because your business isn't worth enough for them to care (check out the quality differences between the enterprise and SMB versions of various products for examples). Given the importance of email to most organizations today, folks are a bit reluctant to hand it over to an outsider with minimal financial incentive to devote resources to their specific problems.

If you're a 5-person business, outsourcing email is likely a good idea, but once you start getting into the teens and twenties or so, it's probably worth a look at your particular circumstances before continuing that assumption.

Full disclosure: I'm currently a local IT guy for a smaller company, with enough on my to-do list that if I thought outsourcing email would work well for my users and save us time & money, I'd be all over it.

I don't buy this as an excuse to not eat decent food. A 3-mile walk doesn't take more than about 45 minutes. Include the return trip, and you're up to an hour and a half. Even if every person in your household works fulltime, you have time to do this at least every couple days. If you're underemployed, you've got even more time. If you're working multiple jobs, you can probably afford a bus pass.

Perhaps I'm more dedicated to decent food than most, but I wouldn't let a few miles keep me away from it. Sure, it would suck to live in one of those "food deserts" and have to walk a few miles to get to decent food, but being poor typically sucks in general, if your idea of a good life is to be able to pay people to do things for you (eg, provide transportation).

Since we're talking about health, I'd feel remiss if I didn't point out that the extra walking helps improve your health, too.

I agree that these things rock. I've been wearing the Keep-Stuff-Out model for a few months now for boating, trail-hiking, and other general wear.

The few weaknesses I've found are the following:

1) They suck in scree fields. A solid boot protects the top of your foot a lot better when you're sliding through sharp rocks.

2) They suck for bushwhacking through the woods (at least in New England). I tried this a few times, but the pointy sticks in old logging sites and various underbrush got me between the toes too many times. I'd love a model where the sole continued up between the toes, so you'd have the rubber to protect you there instead of the light fabric on the current models.

3) They suck in the mud. The soles just don't grip well there, despite their impressive performance elsewhere; they probably need some sort of lug or something to fix this. A friend recommended wearing a sock over them for improved mud traction, but I haven't had a chance to try this yet.

I'm really surprised at how well they work, though. I love them for trails and water especially. I haven't carried more than 35 pounds or so with them yet, but was surprised at how much I prefer them over more sturdy shoes for light backpacking and climbing approaches. These are definitely my favourite shoes.

If you go this route, make sure you get their Enterprise product. We used that for several years and had no problems with it, but were eventually moved into their SMB offering due to our size (~30 licenses), and I found the SMB product's management capabilities to be awful, the interface to be buggy and unstable, etc. Our VAR recently gave us a heads up that they'd changed the product again, and confirmed it would require another round of uninstall/reinstall, so we took the opportunity to evaluate our options and have moved to another vendor.

The I/O. On a mainframe, you can run a query and generate large datasets so fast it'll blow your mind (in 2002-ish, say tens of gigabytes). On the mainframe it's no big deal, and you can run queries like that all day and never have any idea how much data you're moving around until you try to move it somewhere else and wonder why it's taking so long.

The mainframe isn't about looking pretty, it's about getting work done, and the folks touting their benefits generally aren't exaggerating. Mainframes aren't generally designed for CPU-heavy tasks, although they certainly can be clustered pretty impressively if you really need lots of CPU. The biggest advantage is that you can really use the CPU's you've got. There are service processors to offload things like memory management, encryption, I/O, virtualization overhead, etc. There are really really fast I/O channels. You typically attach them to really really fast disk and tape. These things together allow you to move a lot of data around very quickly, and get a lot of work done.

Additionally, lots of large companies have lots of man-hours invested in systems that run their businesses. I've seen attempts to reimplement some of the beasts to get them off the mainframe, and they typically don't go well. I've also seen assembly code written in the late 1960's still running in production more than 35 years later. The underlying hardware had been upgraded many times, but IBM made sure the old stuff would still work.

Things like this are worth a lot of money to a certain class of purchaser.