I'll give you 2, but, uh, Vietnam? Tibet? India? You don't have to go back even as far as Korea to find China invading other countries and committing atrocities.
This idea is as ridiculous as the opposite extreme, which is imagining that giving the government more money will lead to better education and other social services.
You're both wrong.
I'll be the first to acknowledge that there are many organizational and institutional issues in government agencies which can blow through influxes of funds without any appreciable improvement in services. Yet it's equally true that there are government agencies and programs which run at efficiency levels which beggar private alternatives in comparison.
Tired aphorisms are never going to be an adequate substitute for an intelligent examination of the actual problems faced and a realistic appraisal of the various strengths and weakness offered by public and private approaches.
Because the supply of land (which is also required for homes) is finite; any project that removes a large chunk of it from the market is going to drive up the price of the remaining available space (and by extension, homes that might be built on it).
The ads are not "relevant" to you, they are what advertisers want you to see.
Those things aren't mutually exclusive.
The advertisers don't have enough information to to give you really relevant ads.
Then isn't the solution, if you want what the GP professes to want, less privacy?
Best thing to do is block ads and just google when you want something.
Ironic that you're citing one of the biggest data-aggregating advertisers out there today as a relevant source, when you appear to be arguing against exactly what they are doing to present you with those results.
I'm not much interested in Hollywood versions of classic books, ever since Peter Jackson took a book that is much shorter than any of the books in the Lord of the Rings trilogy and stretched it out to what promises to be a trilogy in it's own right.
I'm not saying it's right for The Hobbit, particularly, but there's nothing inherently wrong with taking a short book and making a long movie, or series of movies, out of it... books are dense, most are given little chance to have all their themes, sub-plots, and characters portrayed on the big screen. It's not always wise to do so, but such a common objection to adaptations is "Aw, they cut my favorite part from the book!" that I think most fans would prefer stretching their favorites out if it meant fitting in more of the source.
Again, not exactly what Jackson is up to, but nothing at all wrong with taking a short book loaded with story and making a movie long enough to do it justice.
...regularly sweeping money into a bank account will also get your account frozen.
I'm not saying I trust PayPal all that much, but this is simply untrue. I have businesses that use a couple of different PayPal accounts, and regular sweeps are de rigeur for us, and we've never had any account frozen by them.
Part of the reason we sweep them is to guard against just that possibility, however.
It's also important to sweep the account you are sweeping into... usually, the wire transfer capability works both ways. So they can, without additional authorization, suck funds back out of your bank account. (if anyone happens to know a bank that will let you prevent this sort of outgoing transaction, I am all ears)
If the funds aren't in that account, you could get hit with an NSF charge from your institution, but you'll have an easier time arguing with them about it than with PayPal, and a $30 bounce charge is a lot less than $50,000 or whatever amount PayPal might decide to sit on instead.
You know, I agree with your sentiment entirely, which is why I feel bad calling this out:
A serious firewall would be a good start.
It's really not. In fact, the firewall is the last thing you should think about.
That's not just because there are so many exploits right now that are for all practical purposes indistinguishable from normal traffic, although that's a good reason, too. It's because the best defenses are always layered defenses, and those start from the inside out.
Far too often I see people begin and end at the firewall. Even if they intended it only be the start, they're thinking rarely progresses much further into the network... why should it? They think about all the stuff the firewall is going to catch, and it seems to take care of so many problems it's hard for them to imagine what else they need to do internally to lock things down. They've succumbed to the "enumerating badness" fallacy, classically described by Marcus Ranum in his must-read Six Dumbest Ideas in Computer Security.
That's exactly backward, though. Where you want to start is at your core data, with the assumption that everything else has already failed, and what can you do to mitigate the disaster of penetration at that last possible level.
Then you work your way out, doing the same thing at each level.
Because almost no one does this, firewalls today are the thin, crunchy shell over the juicy taste explosion of vulnerable systems that crackers crave.
Yeah, but the only "problems" with plastic bags were also with the users. So why try to pin the blame there now? Just regulate cloth bags, too!
I'm waiting for this whole exercise in un-scientific nanny-stateism to run full circle. My only problem is that I no long have a state-approved bag in which to put the popcorn.
Hansel and Gretel shove a little old lady into on oven and broil her, and that's been broadly accepted as children's fare for two hundred years. A little justifiable homicide shouldn't be a big issue all of a sudden.
As others have said, it's perfectly possible to get a job in IT without the corresponding degree. But if that's what you're interested in, and you're looking at CS programs, why not do both? Apply or start in on the CS degree and simultaneously look for a job in the industry. The fact that you are at least starting down that path educationally might assuage some potential employers who might otherwise look at your move as one tinged with desperation ("Couldn't get into grad school, now hopes we're going to pay him for his tech hobby while he re-groups and looks for another psych program... no thanks!").
I wish I could tell you more about the job environment and the relative merits of comp-sci degrees these days but I suspect they've changed since the late nineties when I got into it. That was the wild west, and employers cared far more about what you could do than what your degree was in. I was already working in IT by the time I started college, and I consciously decided against a CS degree... at the time, the degree programs I was looking at were hopelessly outdated compared to the technologies I was already working with.
I got my degree in English instead, and I've never regretted it. In fact, communications skills have been some of my most valuable assets when competing for jobs. If you have practical knowledge and the ability to articulate it, you're far more valuable in most IT organizations than a geek who may know more, but can't communicate it. So your psych degree might actually prove more useful than you think.
But if you have the resources to go on and get a CS degree also, and you really want to work in the IT industry, then you should go ahead and get started on it.
"Considering how much talk there is of an enterprise false flag operation, if it was ever intended it probably won't happen because of all the talk about it."
As I was idly paging through the comments thinking about how many of them were jumping to outlandish, unsubstantiated conclusions about why the poor submitter was being asked to come up with metrics, I also realized that pretty much nobody (in the finest tradition of Slashdot) has bothered to answer the actual question: "I'm wondering what people opinions are on what good metrics should be in regards to mttr mtbf etc." I think I misunderstood this at first as well... in light of what he does say about the goals ("...determining if we are performing above or below what is considered optimal") I don't think he's asking what metrics to measure or whether or not we think doing so is any good, but instead what reliable industry benchmarks are for those metrics, so he can tell his boss what is "optimal" or not about their operation.
Well, shibby, sorry, but I don't think there are such things, or at least none relevant enough to take back to your management team. The only way to get anything meaningful out of metrics (obviously a lot of other posters are arguing you'll get nothing meaningful out of them; I disagree, but it may not matter either way if those are your orders) is to establish baselines for your organization and track future performance against those. It will take a while and it will have to be viewed in context to be worthwhile... important points to make when you are presenting your findings to management.
I'm being optimistic and assuming genuine business goals and a desire to understand IT operations on the part of non-technical managers are the point of this request, not some haphazard effort to chop down a three-person department, but it is also worth passing along some of the critiques that are being posted here. On the other hand, if you don't already, you should understand that not all managers are buggers, and that many of the better ones have legitimate reasons for trying to understand what is going on in their IT department. We often forget how mysterious what we do looks to the un-initiated, and I have seen enough poorly run IT departments to sympathize with non-technical managers who are grasping for the tools to understand theirs. The point being, getting defensive and obstructive in the face of these requests isn't always the brightest idea; instead, you can look at it as an opportunity to present some of your perspectives and difficulties to managers who are finally prepared to hear about them (after all, they did ask!). They may not have the time or horsepower to learn everything you do in depth, but it is possible to analyze operations based on the right sort of shorthand.
The cynics may be right; only you will know. But I've seen companies run down by their IT departments as often as I've seen IT departments run down by the management team, so performance concerns on both sides are well-founded. Anyone who thinks their manager shouldn't ask for a suitably abstracted toolset for judging performance is asking for a stupid manager.
Sorry, I guess I was not clear enough about this; it's a generalized number that has nothing to do with either the individual tickets or the individual users. It's measured across the board: Monthly Tickets/Total Users. It's a gauge of the department, not of specific people.
It's not unusual for management to be clueless about what exactly it is that their IT staff does on a daily basis, nor is it unnatural that they should take an interest. Often, it's a good sign when they actually ask the guys doing the work what the metrics should be... it indicates some degree of trust, and they haven't simply read an "IT Management for Dummies" book over the weekend laying out some arbitrary system that isn't going to fit your organization.
As a more cynical commenter points out, it also provides the opportunity to create a measurement system that you can game to make you look good. But I think it isn't a terrible sign that the bosses care what their employees are up to. It may represent an opportunity to explain what you think is important that perhaps they hadn't considered previously.
As folks have already mentioned, time to answer and time to resolve are both important, and I think you have to watch for re-opened as well to curb "how fast can I shove this under the bed?" resolution games.
My favorite is average tickets per user, though. Particularly on a small team, what you really want to gear your measurements toward is preventing incidents in the first place. It is helpful to know what your overall ticket volume looks like, then, and to aim to decrease it over time in the same way you might try to decrease time to answer and time to resolve. That's important, because as the previous article suggests, if you will get what you measure... and your overall goal should not simply be to answer tickets faster and resolve them more quickly, but to not have as many in the first place*. Every issue represents a waste of somebody's time and therefore corporate resources that could be put to more productive uses. Steadily decreasing mtta and mttr are nothing to cheer about if your ticket count is increasing.
But you can keep it simple. You can drown yourself in metrics and lose sight of why you're tracking them and what you really want to accomplish. You may not really need any more than these few; better to start small and add what you need when you need it. I know there's always tension over getting a system in place that can capture what you need for historical purposes when you realize you need to know something new down the road, but resist the urge to over-collect. Half the time you won't need it all and are just wasting time getting it in the system.
* There is a caveat to this; in some organizations, I actually DO want to see an increasing ticket/user count, at least for a time. This is something I shoot for when relations between IT and users have broken down badly enough that users have stopped reporting problems to IT because they feel it's useless, and their issues are never resolved anyway. In those cases, a rising ticket count can represent an increasing trust level, which is good. You generally won't fix issues you don't know about.
Zittrain's been peddling this load of manure argument for a long time now, and as far as I am concerned he has been consistently disproven time after time. It's not that what he points out is not a factor, so much that he ignores the rest of the story, which is that the "generative spirit" continually finds ways to break down the walls, create alternatives, and generally keep innovating despite (and at times, because of) the controls the gardeners put in place.
He equally ignores the fact that the vast majority of users of open technologies never did, or ever would have, engaged in any truly generative behavior. And there's nothing wrong with that. What was a problem was that the price of keeping things open was often inhibiting the normal, consumptive uses of that larger group.
What we have now is by no means the perfect system but it's considerably more balanced than it was before, and there's no evidence whatsoever of the epic collapse of innovation Zittrain has been forecasting for years.
You might have thought that getting burned badly once already might have lead to a renewed emphasis on security and a commitment to best practices in securing important data. Huh. I guess the "can't happen here" clock must have reset already (as well it might have, since I only see one other comment here on Slashdot, of all places, indicating that anyone else remembered the kerfuffle over the Half-Life 2 source theft).
Because it's not a bad question. You're getting answers from a lot of people who are either so buried in the deeply technical side of things or locked into the past that they don't really understand it. Having shepherded a couple of dreamy startups through this phase, though, I don't think you are either crazy or necessarily under-qualified to make a successful site. To be honest, it no longer takes the hardcore technical skills that it once did, if in fact it ever did. Technical competency is over-rated by technical people; there are super-successful web businesses out there that started out (and sometimes even continued) with really shoddy coding and infrastructure setup. Craigslist and PlentyOfFish come to mind as examples. I know several others without such name recognition but which nonetheless did quite well for their owners, who slipped along with very basic programming skills and almost no hardware competency whatsoever.
Having the ability to outsource your infrastructure makes it even easier to do this today. I'm going to stay away from the "C" word because it's so shot through with marketing dross and misunderstanding now. But it's entirely possible to effectively do away with almost all the Windows admin if that's not your strength by going with hosted services. You are probably a long, long way from having to worry about Windows/LAMP stack comparisons even at your stated traffic goals, and using a hosted service will abstract that to the point where you aren't going to need to worry about it anyway. I wish you the best, but the reality is also that few sites make it big anyway, so while scalability is certainly something to consider at this stage, you shouldn't allow it to hobble your choices excessively. If you actually get there, it's almost certain you are going to have both the resources and the need to rip everything up and re-do the entire site from scratch once or twice along the way anyhow. You can re-tool then if you must.
Abstracting hardware doesn't absolve you from making other design choices that will afford scalability, and you should have some understanding of what's going on under the hood so you can make those appropriately. But you don't need all that to get started. I don't know anyone, at any skill level, who actually correctly made all the right choices on their first pass. You'll be learning along the way. That's actually an advantage; tech is filled with people who found their comfort levels and can't adjust to newer models.
It sounds like you are asking as much about your dev environment as production. I would say "yes," move it all to a hosted environment. At this stage, you don't need to be worrying about the underlying nuts and bolts. Get up and running quickly and easily. Be flexible and make adjustments along the way. You probably don't even need to go with a full-on PaaS provider right now, either; get a cheap hosting plan with a company that will help you scale when you need to. Depending on your service requirements, you can go with best of breed hosting to find the most efficient solutions for your various problems... use a SaaS vendor for version control, use a CDN for content hosting, and so on. It's cheap, it's fast, and it reduces the time and cost of failure. Failure is undoubtedly something you will run into a few times along the way. That's going to happen whether you are a technical genius or just some schmoe with a good idea. Build it in to your plans; don't over-invest (whether in time or money) in things until you can see better how things are working out.
If you have a good idea, don't be too afraid if you don't know what you are doing. A lot of the best people don't. One of the most valuable lessons you can learn is what not to spend time on, and a lot of things that certain folks here on Slashdot hold dear are things that you don't necessarily need to spend a lot of time on right now. Prove your concepts first. If you turn into the next Facebook, you can worry about infrastructure then. Until then, don't let the idea that you need a Facebook-worthy infrastructure before getting started to hold you back. Re-format that VM server into a games machine and go rent time elsewhere.
IANAL either, but I know that passing the bar is a state-by-state test; you don't just take one test that covers the laws of all the states, you take a test for the state you are going to be licensed in (or the federal version, but that only covers federal law). So it's entirely reasonable he wouldn't know about the precise details of the law in "most states" even if he picked up a general knowledge in law school.
It's a mystery to me what "satisfactorily stable" consists of for people who point out availability as a problem with cloud solutions. As a rule, enterprises don't publish their internal downtime statistics, but I can tell you that for a large chunk of them, it's far worse than the occasional Gmail outages. And no one who makes that argument ever seems to look at the necessary companion to stability, which is cost. What does it cost you to be satisfactorily stable running internally? For most businesses, again, it's a lot more than an Apps subscription, for a lot less stability.
As for off-line access, Gears is already available to allow offline access to Gmail, but if you don't like that, you can just as easily configure the same sort of standard POP3 or IMAP client-side application that you would use with any other mail service, with the same capabilities should your connection be severed.
It also seems to me that people over-estimate what actually gets done in many offices when network access goes out, regardless of the off-line capabilities of clients, but that's another arguement.
Slashdot Mirror
I think he understands you a hell of a lot better than you understand him.
I'll give you 2, but, uh, Vietnam? Tibet? India? You don't have to go back even as far as Korea to find China invading other countries and committing atrocities.
He's got a terrific point and you keep helping him make it with your rather oblivious use of language.
This idea is as ridiculous as the opposite extreme, which is imagining that giving the government more money will lead to better education and other social services.
You're both wrong.
I'll be the first to acknowledge that there are many organizational and institutional issues in government agencies which can blow through influxes of funds without any appreciable improvement in services. Yet it's equally true that there are government agencies and programs which run at efficiency levels which beggar private alternatives in comparison.
Tired aphorisms are never going to be an adequate substitute for an intelligent examination of the actual problems faced and a realistic appraisal of the various strengths and weakness offered by public and private approaches.
But... but... but... everyone else in this thread is saying that you get what you pay for! How could that logic possibly be wrong? :/
Because the supply of land (which is also required for homes) is finite; any project that removes a large chunk of it from the market is going to drive up the price of the remaining available space (and by extension, homes that might be built on it).
Those things aren't mutually exclusive.
Then isn't the solution, if you want what the GP professes to want, less privacy?
Ironic that you're citing one of the biggest data-aggregating advertisers out there today as a relevant source, when you appear to be arguing against exactly what they are doing to present you with those results.
I'm not saying it's right for The Hobbit, particularly, but there's nothing inherently wrong with taking a short book and making a long movie, or series of movies, out of it... books are dense, most are given little chance to have all their themes, sub-plots, and characters portrayed on the big screen. It's not always wise to do so, but such a common objection to adaptations is "Aw, they cut my favorite part from the book!" that I think most fans would prefer stretching their favorites out if it meant fitting in more of the source.
Again, not exactly what Jackson is up to, but nothing at all wrong with taking a short book loaded with story and making a movie long enough to do it justice.
I'm not saying I trust PayPal all that much, but this is simply untrue. I have businesses that use a couple of different PayPal accounts, and regular sweeps are de rigeur for us, and we've never had any account frozen by them.
Part of the reason we sweep them is to guard against just that possibility, however.
It's also important to sweep the account you are sweeping into... usually, the wire transfer capability works both ways. So they can, without additional authorization, suck funds back out of your bank account. (if anyone happens to know a bank that will let you prevent this sort of outgoing transaction, I am all ears)
If the funds aren't in that account, you could get hit with an NSF charge from your institution, but you'll have an easier time arguing with them about it than with PayPal, and a $30 bounce charge is a lot less than $50,000 or whatever amount PayPal might decide to sit on instead.
You know, I agree with your sentiment entirely, which is why I feel bad calling this out:
It's really not. In fact, the firewall is the last thing you should think about.
That's not just because there are so many exploits right now that are for all practical purposes indistinguishable from normal traffic, although that's a good reason, too. It's because the best defenses are always layered defenses, and those start from the inside out.
Far too often I see people begin and end at the firewall. Even if they intended it only be the start, they're thinking rarely progresses much further into the network... why should it? They think about all the stuff the firewall is going to catch, and it seems to take care of so many problems it's hard for them to imagine what else they need to do internally to lock things down. They've succumbed to the "enumerating badness" fallacy, classically described by Marcus Ranum in his must-read Six Dumbest Ideas in Computer Security.
That's exactly backward, though. Where you want to start is at your core data, with the assumption that everything else has already failed, and what can you do to mitigate the disaster of penetration at that last possible level.
Then you work your way out, doing the same thing at each level.
Because almost no one does this, firewalls today are the thin, crunchy shell over the juicy taste explosion of vulnerable systems that crackers crave.
Yeah, but the only "problems" with plastic bags were also with the users. So why try to pin the blame there now? Just regulate cloth bags, too!
I'm waiting for this whole exercise in un-scientific nanny-stateism to run full circle. My only problem is that I no long have a state-approved bag in which to put the popcorn.
Hansel and Gretel shove a little old lady into on oven and broil her, and that's been broadly accepted as children's fare for two hundred years. A little justifiable homicide shouldn't be a big issue all of a sudden.
As others have said, it's perfectly possible to get a job in IT without the corresponding degree. But if that's what you're interested in, and you're looking at CS programs, why not do both? Apply or start in on the CS degree and simultaneously look for a job in the industry. The fact that you are at least starting down that path educationally might assuage some potential employers who might otherwise look at your move as one tinged with desperation ("Couldn't get into grad school, now hopes we're going to pay him for his tech hobby while he re-groups and looks for another psych program... no thanks!").
I wish I could tell you more about the job environment and the relative merits of comp-sci degrees these days but I suspect they've changed since the late nineties when I got into it. That was the wild west, and employers cared far more about what you could do than what your degree was in. I was already working in IT by the time I started college, and I consciously decided against a CS degree... at the time, the degree programs I was looking at were hopelessly outdated compared to the technologies I was already working with.
I got my degree in English instead, and I've never regretted it. In fact, communications skills have been some of my most valuable assets when competing for jobs. If you have practical knowledge and the ability to articulate it, you're far more valuable in most IT organizations than a geek who may know more, but can't communicate it. So your psych degree might actually prove more useful than you think.
But if you have the resources to go on and get a CS degree also, and you really want to work in the IT industry, then you should go ahead and get started on it.
"Considering how much talk there is of an enterprise false flag operation, if it was ever intended it probably won't happen because of all the talk about it."
That's just what they want you to think!
Well, that's job security, innit?
As I was idly paging through the comments thinking about how many of them were jumping to outlandish, unsubstantiated conclusions about why the poor submitter was being asked to come up with metrics, I also realized that pretty much nobody (in the finest tradition of Slashdot) has bothered to answer the actual question: "I'm wondering what people opinions are on what good metrics should be in regards to mttr mtbf etc." I think I misunderstood this at first as well... in light of what he does say about the goals ("...determining if we are performing above or below what is considered optimal") I don't think he's asking what metrics to measure or whether or not we think doing so is any good, but instead what reliable industry benchmarks are for those metrics, so he can tell his boss what is "optimal" or not about their operation.
Well, shibby, sorry, but I don't think there are such things, or at least none relevant enough to take back to your management team. The only way to get anything meaningful out of metrics (obviously a lot of other posters are arguing you'll get nothing meaningful out of them; I disagree, but it may not matter either way if those are your orders) is to establish baselines for your organization and track future performance against those. It will take a while and it will have to be viewed in context to be worthwhile... important points to make when you are presenting your findings to management.
I'm being optimistic and assuming genuine business goals and a desire to understand IT operations on the part of non-technical managers are the point of this request, not some haphazard effort to chop down a three-person department, but it is also worth passing along some of the critiques that are being posted here. On the other hand, if you don't already, you should understand that not all managers are buggers, and that many of the better ones have legitimate reasons for trying to understand what is going on in their IT department. We often forget how mysterious what we do looks to the un-initiated, and I have seen enough poorly run IT departments to sympathize with non-technical managers who are grasping for the tools to understand theirs. The point being, getting defensive and obstructive in the face of these requests isn't always the brightest idea; instead, you can look at it as an opportunity to present some of your perspectives and difficulties to managers who are finally prepared to hear about them (after all, they did ask!). They may not have the time or horsepower to learn everything you do in depth, but it is possible to analyze operations based on the right sort of shorthand.
The cynics may be right; only you will know. But I've seen companies run down by their IT departments as often as I've seen IT departments run down by the management team, so performance concerns on both sides are well-founded. Anyone who thinks their manager shouldn't ask for a suitably abstracted toolset for judging performance is asking for a stupid manager.
Sorry, I guess I was not clear enough about this; it's a generalized number that has nothing to do with either the individual tickets or the individual users. It's measured across the board: Monthly Tickets/Total Users. It's a gauge of the department, not of specific people.
It's not unusual for management to be clueless about what exactly it is that their IT staff does on a daily basis, nor is it unnatural that they should take an interest. Often, it's a good sign when they actually ask the guys doing the work what the metrics should be... it indicates some degree of trust, and they haven't simply read an "IT Management for Dummies" book over the weekend laying out some arbitrary system that isn't going to fit your organization.
As a more cynical commenter points out, it also provides the opportunity to create a measurement system that you can game to make you look good. But I think it isn't a terrible sign that the bosses care what their employees are up to. It may represent an opportunity to explain what you think is important that perhaps they hadn't considered previously.
Bad metrics suck, good metrics are useful data.
As folks have already mentioned, time to answer and time to resolve are both important, and I think you have to watch for re-opened as well to curb "how fast can I shove this under the bed?" resolution games.
My favorite is average tickets per user, though. Particularly on a small team, what you really want to gear your measurements toward is preventing incidents in the first place. It is helpful to know what your overall ticket volume looks like, then, and to aim to decrease it over time in the same way you might try to decrease time to answer and time to resolve. That's important, because as the previous article suggests, if you will get what you measure... and your overall goal should not simply be to answer tickets faster and resolve them more quickly, but to not have as many in the first place*. Every issue represents a waste of somebody's time and therefore corporate resources that could be put to more productive uses. Steadily decreasing mtta and mttr are nothing to cheer about if your ticket count is increasing.
But you can keep it simple. You can drown yourself in metrics and lose sight of why you're tracking them and what you really want to accomplish. You may not really need any more than these few; better to start small and add what you need when you need it. I know there's always tension over getting a system in place that can capture what you need for historical purposes when you realize you need to know something new down the road, but resist the urge to over-collect. Half the time you won't need it all and are just wasting time getting it in the system.
* There is a caveat to this; in some organizations, I actually DO want to see an increasing ticket/user count, at least for a time. This is something I shoot for when relations between IT and users have broken down badly enough that users have stopped reporting problems to IT because they feel it's useless, and their issues are never resolved anyway. In those cases, a rising ticket count can represent an increasing trust level, which is good. You generally won't fix issues you don't know about.
Zittrain's been peddling this load of manure argument for a long time now, and as far as I am concerned he has been consistently disproven time after time. It's not that what he points out is not a factor, so much that he ignores the rest of the story, which is that the "generative spirit" continually finds ways to break down the walls, create alternatives, and generally keep innovating despite (and at times, because of) the controls the gardeners put in place.
He equally ignores the fact that the vast majority of users of open technologies never did, or ever would have, engaged in any truly generative behavior. And there's nothing wrong with that. What was a problem was that the price of keeping things open was often inhibiting the normal, consumptive uses of that larger group.
What we have now is by no means the perfect system but it's considerably more balanced than it was before, and there's no evidence whatsoever of the epic collapse of innovation Zittrain has been forecasting for years.
You might have thought that getting burned badly once already might have lead to a renewed emphasis on security and a commitment to best practices in securing important data. Huh. I guess the "can't happen here" clock must have reset already (as well it might have, since I only see one other comment here on Slashdot, of all places, indicating that anyone else remembered the kerfuffle over the Half-Life 2 source theft).
Because it's not a bad question. You're getting answers from a lot of people who are either so buried in the deeply technical side of things or locked into the past that they don't really understand it. Having shepherded a couple of dreamy startups through this phase, though, I don't think you are either crazy or necessarily under-qualified to make a successful site. To be honest, it no longer takes the hardcore technical skills that it once did, if in fact it ever did. Technical competency is over-rated by technical people; there are super-successful web businesses out there that started out (and sometimes even continued) with really shoddy coding and infrastructure setup. Craigslist and PlentyOfFish come to mind as examples. I know several others without such name recognition but which nonetheless did quite well for their owners, who slipped along with very basic programming skills and almost no hardware competency whatsoever.
Having the ability to outsource your infrastructure makes it even easier to do this today. I'm going to stay away from the "C" word because it's so shot through with marketing dross and misunderstanding now. But it's entirely possible to effectively do away with almost all the Windows admin if that's not your strength by going with hosted services. You are probably a long, long way from having to worry about Windows/LAMP stack comparisons even at your stated traffic goals, and using a hosted service will abstract that to the point where you aren't going to need to worry about it anyway. I wish you the best, but the reality is also that few sites make it big anyway, so while scalability is certainly something to consider at this stage, you shouldn't allow it to hobble your choices excessively. If you actually get there, it's almost certain you are going to have both the resources and the need to rip everything up and re-do the entire site from scratch once or twice along the way anyhow. You can re-tool then if you must.
Abstracting hardware doesn't absolve you from making other design choices that will afford scalability, and you should have some understanding of what's going on under the hood so you can make those appropriately. But you don't need all that to get started. I don't know anyone, at any skill level, who actually correctly made all the right choices on their first pass. You'll be learning along the way. That's actually an advantage; tech is filled with people who found their comfort levels and can't adjust to newer models.
It sounds like you are asking as much about your dev environment as production. I would say "yes," move it all to a hosted environment. At this stage, you don't need to be worrying about the underlying nuts and bolts. Get up and running quickly and easily. Be flexible and make adjustments along the way. You probably don't even need to go with a full-on PaaS provider right now, either; get a cheap hosting plan with a company that will help you scale when you need to. Depending on your service requirements, you can go with best of breed hosting to find the most efficient solutions for your various problems... use a SaaS vendor for version control, use a CDN for content hosting, and so on. It's cheap, it's fast, and it reduces the time and cost of failure. Failure is undoubtedly something you will run into a few times along the way. That's going to happen whether you are a technical genius or just some schmoe with a good idea. Build it in to your plans; don't over-invest (whether in time or money) in things until you can see better how things are working out.
If you have a good idea, don't be too afraid if you don't know what you are doing. A lot of the best people don't. One of the most valuable lessons you can learn is what not to spend time on, and a lot of things that certain folks here on Slashdot hold dear are things that you don't necessarily need to spend a lot of time on right now. Prove your concepts first. If you turn into the next Facebook, you can worry about infrastructure then. Until then, don't let the idea that you need a Facebook-worthy infrastructure before getting started to hold you back. Re-format that VM server into a games machine and go rent time elsewhere.
Real nerds who spend their days up to their elbows in Internet plumbing knew exactly what it was about at first glance.
IANAL either, but I know that passing the bar is a state-by-state test; you don't just take one test that covers the laws of all the states, you take a test for the state you are going to be licensed in (or the federal version, but that only covers federal law). So it's entirely reasonable he wouldn't know about the precise details of the law in "most states" even if he picked up a general knowledge in law school.
It's a mystery to me what "satisfactorily stable" consists of for people who point out availability as a problem with cloud solutions. As a rule, enterprises don't publish their internal downtime statistics, but I can tell you that for a large chunk of them, it's far worse than the occasional Gmail outages. And no one who makes that argument ever seems to look at the necessary companion to stability, which is cost. What does it cost you to be satisfactorily stable running internally? For most businesses, again, it's a lot more than an Apps subscription, for a lot less stability.
As for off-line access, Gears is already available to allow offline access to Gmail, but if you don't like that, you can just as easily configure the same sort of standard POP3 or IMAP client-side application that you would use with any other mail service, with the same capabilities should your connection be severed.
It also seems to me that people over-estimate what actually gets done in many offices when network access goes out, regardless of the off-line capabilities of clients, but that's another arguement.