According to the Boston Globe, police pay in Massachusetts can exceed $250k, not including benefits.
They could change the timeouts. If an iMessage is sent to a destination that's a phone number (instead of an email address), and a device configured to receive messages for that phone number has not checked in within the past 5-7 days, deactivate iMessage for that phone number until a configured device checks in again.
I agree this is mostly user error and haven't had any problems resolving it for people who've asked me about it, but people don't typically anticipate this result when switching phones, so containing the undesired effects to a shorter transition window would seem like a helpful thing to do.
IMHE tape is always an order of magnitude slower than the advertized speed, so it is likely even worse than what you calculated.
If your tapes are writing that slowly, something is wrong, and I'd be worried about shoe-shining. Without putting much effort into it, my LTO5 jobs currently run at around 125-135MB/s. With modern tape, it helps a lot to stage to disk first, or get software that can multiplex backup streams to keep the tape buffers fed.
You may not be a native English speaker, so you may not be aware of the fact that we have no gender-neutral, third person, singular pronoun for a person.
This isn't true. There is a gender-neutral, third-person, singular pronoun for a person. In the nominative case, that pronoun is "he". In the objective case, it's "him".
Yes, it's ambiguous that the gender-neutral pronouns are spelled and pronounced the same as the masculine ones, but it's far from the only case in English where we've got two words spelled and pronounced the same that mean different things. I always figured if people wanted to communicate in an unambiguous fashion, they'd choose a language other than English..
Of course this is a chicken-egg problem in that it then ties back into DNSSEC and root level trust in DNSSEC needs to be solved (through CAs for now) but it decouples the problem and leverages the architecture of DNSSEC (we really do need it anyways) to provide arbitrary certificate trust without putting undo burden on DNS. If we are going to have to have DNSSEC to fix DNS we may as well use it for more than just name to IP resoultion. There is no reason to solve the trust problem more than once since and as long as we use DNS based hierarchies to specify machines or end users (e-mail accounts) we have to trust DNS. The fact that today pre-DNSSEC we blindly trust unsigned DNS replies is the only reason the parallel certificate hierarchy exists at all.
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?
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?
Perhaps not, depending on the other load the system is working on. Because of the way VCPUs are scheduled (at least in VMWare) that 8-vCPU VM won't get a time-slice until such time as there are 8 real cores available for the duration of that slice.
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.
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.
So what you are saying is that you or your company can't deliver services that you or your company promiss so it's your customer's fault for not buying additional services from other people that can?
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..".
Still, I'm a bit surprised that they would try this, completely eliminating the snow will slow the warm-up process in spring, and any vegetation will have a much harder time coming back. The snow prevents the ground from freezing as deeply - without it a lot of plant roots die during winter. Do they really have so few plants in Moscow that this is no big deal? No parks or anything?
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.
Sounds like a sad, dreary place if so.
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.
Umm, an hour of downtime doesn't mean your data is gone. I'll also echo earlier comments -- locally hosted email generally has more problems, as no company but the largest enterprise has the same magnitude of IT equipment and experience as Google.
I've never really understood why so many Slashdotters have this attitude about hosted services. Perhaps they are local IT folks for smaller companies, and fear for their jobs?
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.
If you're poor enough that the difference between $1.50 Cambell's soup and $1 frozen pizza is critical, then you're not going to have the time or the $3 for bus fare to get to the real grocery store a few miles away. There really are areas where you can't easily get to a grocery store: they are called "food deserts" by those who work on issues surrounding food supplies in poor urban areas.
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.
Whats so special/magical about a mainframe?
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.
Our mainframes serve ancient text based interfaces thru terminal emulator apps, and it doesn't look all that impressive either. What is it about a mainframe that enables such a large amount of computing power to be condensed into a refridgerator sized package? Or are some folks around here exagerrating considerably?
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.