August 2011 Archives

Identity firewalls

The ongoing nymwars surrounding Google's decision to require legal-looking names for users of their invite-only Google Plus social networking site are still going strong. The term "nymwars" is derived from 'pseudonym', the thing Google is banning.

Yeah, I have an interest in this.

As I mentioned last month I'm of the generation that grew up using handles for our online presence, so I have long experience using names-that-aren't-on-my-government-ID to identify myself. Heck, whole groups of people only knew me by those [8|10|16]-character-or-less handles. From what I've seen, it seems like it is my generation that is leading the nymwar fight.

For years I've carefully curated what I allow on the Internet that is associated with my real name. I knew w-a-y back in 2000 that what you say online (back then I was worried about Usenet posts) is on your permanent record and have treated my online interactions like that ever since. If you drop my legal name into your search engine of choice, one of the top hits will be my LinkedIn profile, which is just as it should be. Other hits will be some posts to mailing lists I made from work firstname.lastname email addresses, but those are OK as well since they're covering technical topics rather than something divisive like political opinions. Facebook will show up as well, but I'm only there to name-squat and keep in touch with certain FB-only people in my life. You can also learn about the other people with my name in this country, though it seems I've done the most internet-visible work in that regard.

I also have a variety of pseudonyms I've used on various social-network oriented sites over the years. You can get from those to here since I occasionally link to my blog posts on those services, but going the other direction is a lot harder. This is intentional. Much like network security, I do firewall certain aspects of my identity from general consumption. I am purposely including opinions and actions in the definition of "Identity", not just the facts that describe me. It is under those pseudonyms slash trusted-zones that I go into the details of my politics, hobbies, and extra-curricular activities.

You know, the kinds of things that can alienate future employers.

Identity firewalling is very much needed since American society as a whole isn't set up to handle:

  • People who parroted their parent's political views while children.
  • People who change their opinions from year to year.
  • People who change their opinions from decade to decade. Or ever, in the case of Presidential candidates.
  • People with unusual hobbies.
  • People who are members of unpopular religious, ethnic, sexual, or technical minorities.
  • People who have unusual personal relationships.
  • People who talk about sex.
  • People who have certain medical conditions.
  • People who do stupid things between the ages of 15-18.
  • People who do stupid things between the ages of 18-24.
  • People who have been convicted of a crime (even while being stupid between 18-24).
  • People who hold extreme views.
  • People with unusual family circumstances.
  • People who are Not From Around Here.
Society can handle each of those, but generally speaking not in employment or elected-office capacities. We have laws specifically banning discrimination on a number of the above points, but that doesn't stop it from happing in private; those laws are there because we do it in private and to prevent it from happening in public in the hopes that eventually we'll stop doing it in private as well.

Speaking as someone who has been subjected to multiple background checks as a condition of employment for more than one job, I can tell you that the standards are a bit higher for someone like me. Anything in my background that suggests poor judgment can be used as a basis for passing over my application. This is why I curate my online identity as closely as I do, because it's hard to guess what online speech of right now will be considered suspect in 20 years.

There have been several news articles in recent years about employers requiring access to the "full profile" on Facebook as a condition of employment. This is done to better assess the character of incoming hires. I have full confidence that, "please add our HR processor to all of your Google Plus circles," will be a similar request in the future. The correct answer to these requests, in my opinion anyway, is "I'm sorry, but I won't work for a place that requires such information." However, if you've been unemployed for 18 months and are about to run out of Unemployment benefits, saying "go away" to a potential employer is not something you're inclined to do even on principle.

This is where maintaining multiple identities really comes into its own. By having that firewall, you can give your potential employer access to all of your G+ circles... for the identity you keep for public consumption. If you've done the separation right, you can survive this invasion of your privacy without having your privates groped quite so firmly. Such identity separation will need to happen until such time that employers and voters no longer care what you did or said 20 years ago.

Google has said that Circles are the best way to segregate your identity. I applaud them for that, since such mechanisms are quite useful. Everyone doesn't want to hear about my medical issues, just fellow sufferers and family. Twitter doesn't offer this kind of segregation, which is why some of the people I follow have more than one twitter account.

As I pointed out above, all it takes is one employer demanding to be added to all of your circles as a condition of employment and that careful segregation goes out the window. People need a stronger separation than just 'circles', a separate profile is that mechanism.

Google: if you fear using your real name, then don't use Google Plus.

To which I say bullshit. Humans are social critters, and all it takes is the right number of people saying, "Good bye Facebook, you can find me on G+", and eventually you have to be on G+ in order to have any social-networking contact with those people. That's a large part of why I'm on Facebook at all, otherwise I wouldn't be there. This will cause people who otherwise would follow this advice to go against their best interests. Maybe they'll use their real name, or initials. Or attempt a pseudonym and hope they don't get caught.

Google: If people don't know you by your real name, add your pseudonyms to your "Other Names" on your profile, people can still find you then. Google cites this as the solution to the, "The people on the Mythbusters forum know me as Cmdr. Keenly, but my knitting friends all know me as CaughtTheWumpus, how would they connect that to $RealName," problem.

Which is true. That mechanism is quite useful for consolidating all of your identity islands into a single googly one. I still maintain that this is a bad idea. Said employer will use that list of names as an index of places to further plunder for your 'character'.

If Google were a smaller player like Diaspora their real-name stance wouldn't mean much. However, since they are the company that drives 75% of the RSS traffic to this very blog, nearly all of the Instant Messaging traffic I personally have seen in the last 4 years, and wrote the operating system for my phone, the impact is somewhat different for them. I've had a good number of my online friends throw Facebook over the side in favor of G+, and enough of them have done so that I feel pressure to go to G+ just so I can follow them.

Because of this, Google's lack of support for firewalled identities is a significant issue. A very significant issue, and one that I'm watching closely.
The Sysadmin space is very broad. We do everything IT, and sometimes that unavoidably includes some management stuff as well. Once in a while we're even entrusted with an actual budget that we can spend without asking anyone first. Sometimes, we're even given minions subordinates.

Because of this, I consider certain management functions to be entirely within the rubric of "professional sysadmin".

  • Justifying large purchases.
  • Justifying changes in strategic direction.
  • Justifying changes in end-user IT management.
  • Justifying product upgrades.
  • Justifying staffing changes.
The observant may notice a common word up there, "Justify." This is because the more senior you get as a sysadmin, the more often you have to go before Management to convince them to do something. This is why having high levels in your "speaker to managers" skill is something you want to develop.

So many of the problems we face are both people problems and technology problems. Take email quotas; the technical problem of ever growing mailboxes is can be resolved by putting a mail quota in place, the people problem of such is convincing everyone that such measures are a good idea. Put the technical solution in place before the people solution, and your users will start putting up Mordac, Preventer of Information Services comics up in their cubes.

So, you need to convince management to buy in. There are a number of ways of doing that, but the most effective (in my experience, anyway) are those that tie decisions to dollars.

Take that email problem. It is entirely possible to build a spreadsheet that takes the costs of the mail system as a whole (storage, servers, mail software, AV software, client software) and distils a cost-per-MB of mail storage. By the way, this is why you learned algebra in school. Take that to Management, and point out that the one big user who has the 5.2GB mailbox is costing $x compared to the average user who is costing ($x/20), and they take notice.

You want them to take notice in this case. They may give you more resources to handle it, provide some management pressure on end-users to keep usage down, or a wild-card option (perhaps taking it to the cloud).

When convincing management that you need to spend big-big money for something (perhaps the storage array housing all of the company crown jewels is about to go out of support) phrasing the persuasion in terms of finance is also very effective. You do have to get the risk-management part of it right (risk-management, something else we have to do), but helping to illuminate the costs of inaction is something that's very useful.

It is my experience that non-technical management only ever really see the direct-costs for things. That's items like hardware purchases, ongoing support contract costs, software license maintenance, software upgrade purchases, and staffing. They rarely get a good look at the indirect costs for things. Indirect costs are things like after-hours calls for handling buggy software, backup system outages due to bad tape-drives, and increased support-contract costs for hardware in the 4+ years old range.

All of these things are entirely within the realm of "professional sysadmin". These sorts of finance problems aren't covered in sysadmin classes, and generally are picked up on-the-job. This is why when anyone asks about how to convince management of things, I help.

"How do I make my own Dropbox without using Dropbox" is a question we get a lot on ServerFault.

And judging by the Dropbox Alternatives question, the answer is pretty clear.


Yes, that Novell thingy.

I've used the commercial version, but the open-source version does most of what the paid one does. I suspect the end-to-end encryption option is not included, possibly due to licensing concerns. But the whole, "I have this one directory on multiple machines that exists on all of 'em, and files just go to all of them and I don't have to think about it," thing is totally iFolder.

The best part is that it has native clients for both Windows and Mac, so no futzing around with Cygwin or other Gnu compatibility layers.

Natural inconvenience

Because really, 'natural disaster' is not what we're dealing with.

Yes, I felt the earthquake. It was me and the one other ex-west-coastie in the office who realized what that was first. It was quite unmistakable in this unreinforced brick-building. The ground just picked us up and dropped us a few times, the kind of motion a building like this just wasn't designed to handle. Some existing damage to the building may have gotten worse. There was a lot of brick dust thanks to the wood rafters dancing around. That's it.

At home we had two casualties. A drinking glass shook itself off a shelf and took a diver, breaking. And a mason-jar leaned against a cabinet door, so when I opened it last night it fell at me, requiring me to parry it into a metal popcorn bowl (loud!) and causing a large bruise on my left middle finger.

And we have a hurricane heading our way.

I'm not worried about the hurricane. On its current track, if we DO get a dead-center hit the eye will have tracked across 300-400 miles of land and will be significantly weakened ("tropical depression"). Far more likely is a glancing blow where it spins off the coast. Irene is a big storm so we would just get some of the western rain-bands. From what I hear, this'll be a lot like the big Winter rain-storms the PacNW gets, so nothing I haven't lived through before.

The value of checklists

This weekend I spent 19 hours in the line of duty, doing quite a few things at our datacenter. We had a 48 hour outage window arranged with our clients, and some things needed to get done in time for others to Q/A the changes. Big, big stuff.

For something this large, we needed a checklist to keep track of it all. I spent the previous week honing it into a workable shape. Even though there were two of us available for the work, I still kept it in a serialized form rather than track items that could be done in parallel as that would have complicated things.

And it was a damned good thing I had that list. At hour 14 of the work, I had been 9 hours without food and wasn't tracking things as well as I would had I been fresh. That checklist provided me with brains-on-a-page so I could be smart when I wasn't actually smart. I could focus on important things like why these VLANs weren't working the way I anticipated, and not wrack my brains for what happens next. If we didn't have that checklist, I most definitely would have forgotten key steps.

Checklists. Useful things, especially when you're going to be under stress or are going to be doing complex things.

Coming up with a 5 year plan

I haven't been asked this, but, hey, it could happen. Businesses ask for five year plans for long-range planning reasons. And sometimes, IT gets asked this as well. And IT is what you call a fast-moving field, and five years is a long time. So. Now what?

At WWU, if you had asked me that I probably could have given you one. Our core mission doesn't change, educate students, thought the details of said can shift on those timescales. My five-year crystal ball could tell you:

  • What major storage systems we've replaced and how the new ones perform
  • What our backup and disaster recovery systems look like
  • What our authentication regime looks like
  • What our monitoring setup looks like and how effective it is
  • What improvements we've made to uptime and overall reliability
And I'd have pretty good confidence that we'd hit those tasks, or at least have a good reason why we didn't. It can happen. In large part because what we do doesn't shift that much.

For my current employer, a company best described as a startup, five years out is so far over the planning horizon as to be beyond a singularity. Our industry is in the beginnings of the consolidation phase, and when that happens... five years is enough for the eDiscovery field to go from over a hundred companies earning over $1M/year to thirty companies over that line, but a few over the $1Bn line. Who knows what side of that we'll be on!

Any five year plan I produce will be either a heinously complex contingency tree, or a statement of desire. I have vastly less confidence that what I lay down now will be close to what we come up with five years down the line.

Because there is a chance we might be one of the billion-dollar players in five years, I'm keeping scalability firmly in mind. But, that's what I'm doing right now, not what I'll be doing five years from now.

Is it impossible to come up with a five year IT plan in a startup? Not at all, but what the likes of us would produce is not even remotely like what the likes of, say, the Red Cross would come up with.

I've said this before, but...

XKCD hit this one on the head. I'm sure nearly all of you read it, but for those that don't...

Spot, freaking, on. As I said, it isn't anything I haven't mentioned before.But nice to see in graphical format.

This specific case is for a "plausible attack on a weak remote web service," which is a different case than cracking stolen password hashes, but one that's a lot easier to carry off. Find a web-login system that doesn't rate-limit or lockout, and you can keep grinding on it until you get through. Length trumps complexity.


If you have intelligence that the target's password method is 3-5 common dictionary words, that problem is a lot easier to crack than "random string of lower-case alpha characters ranging from 16 to 70 characters in length". Still, it'll take a while. And for the remote attacker grinding on "admin", probably not a safe assumption.
As a moderator on ServerFault I run into a lot of the iffy questions. Our users flag them for moderator attention and we deal with them. Some are obviously wrong enough to get dealt with through the normal close-voting process without the mod-hammer being involved. Along the way, we mods do run into some differing opinions on certain nuances of the FAQ. I'll be covering some of the more frequently misunderstood areas of that august document.

#4: In a Professional Capacity
The FAQ states: "Server Fault is for system administrators and desktop support professionals, people who manage or maintain computers in a professional capacity."

The most common misconception by new people, not old-timers, is this adage:

This is ServerFault, and I have a Server. Therefore this question belongs. QED.

These are the people we throw at the FAQ. As the FAQ clearly states, it's not just any servers here, it's server-stuff in a professional capacity.

All kinds of people run servers, but not everyone does so professionally. One of the key differentiators between ServerFault and all of the other public sysadmin hangouts that have emerged over the years is that the scope is set to explicitly not include casual server-stuff. Wondering how to scale your Minecraft server is not topical (unless you're doing so for profit, at which point say so). Wondering how to scale your memcached infrastructure for better overall application performance is.

But what is "professional?"

The userbase has had a lot of talk about this in the past, and there are still some divisions. We've lost some top users because they thought the ServerFault defacto definition was not restrictive enough. One thing I've noticed over my career is that system administrators as a class have a low tolerance for stupidity cluelessness, they get enough of that at work. Cluelessness is not professional, so when the clue-free start asking questions and not getting shot down in short order it grates. So they leave.

"Someone who manages servers and networks for pay" is one broad definition, but there are a lot of clueless people doing the job that are completely out of their depth. Some of our users roll in certain minimum skills, such as sufficient research capabilities to have found and tried some things before coming to ServerFault for the fix. Still others seem to have a nebulous smell-test, which is subjective and hard to pin down in text.

The top system administrators I've know have all been good at one thing. And that is the ability to research problems, find possible solutions, test them, analyze how that changed the problem presentation, and refine the research parameters to begin the cycle anew. You learn a lot by doing this, and sysadmins need to learn a lot and do so continually.

When we see questions on SF that show this pattern, and they're here on SF because they've run into something intractable to their research skills, we smile and answer when we can. Sometimes all we need to do is show a research path they'd missed and off they go. Others, we point out faults in their analysis, which causes them to refine their search terms, and solutions ahoy!

These are our people. They belong here, even if it turns out they're hobbyists (though beware of the dreaded 'home' word). It's the outlook that reflects so well upon them.

People who deal with problems by gathering a bunch of data and throwing it at a bunch of nominal experts in the strenuous hope that an answer will fall out the other end are not our people. All too often, these questions lack the right kinds of data for us to come up with answers and we fall into iterative, "have you tried?" loops. Those sorts of questions are a better fit for full up forums, where extended discussions, back-and-forth, trial and error, and overall one on one extensive interaction are possible. Questions requiring this level of hand-holding are a very bad fit for ServerFault, and they tend to get ignored or flagged 'low-quality' as a proxy for a 'delete this crap' flag.

And yet...

We do get occasional questions from sysadmins who are working out of their field of expertise for some reason and need help. The Windows admin suddenly having to crack a BGP routing problem. The MySQL expert suddenly thrown into MS-SQL. The Cisco expert who just had a bunch of Juniper kit dropped in their lap. The Apache guru suddenly dealing with IIS (these tend to include swearing). When you're out of your depth, it's hard to ask good questions. You don't know enough yet to frame them right for the experts.

Is this a "professional" problem? Not so much, it's more of a "bad question" problem. Especially if they're a frequent user on SF, we will do what we can to help, going so far as to inviting them into a chat-room for intensive one-on-one. They've proven they are professional by their other work on SF. This is not a courtesy we provide to brand new users. Double-standard? Yep, but that's what reputation systems are for.

The second most common misconception is this one:

This is a pre-production environment I'm building for eventual deployment to production. That's professional!
Not according to us, at least. We scope "professional capacity" rather closely around stuff that's running in production. This can be a hard distinction to make since we're supposed to solve problems in pre-production before pushing to production. We've found that scoping things this way makes it very clear that the following two cases are equivalent:

  • I bought a VPS running CentOS and want to build web-sites on it. How do I install nginx to it?
  • How do I get VHOSTs to work with MAPP on my mac?

Unfortunately, this also excludes questions like these:

  • I'm swapping out all of my old Catalyst-based distribution layer for an Extreme-based programmable layer. How do I get VRRP working during the transition?
  • During our test migrations to Exchange 2012 from Exchange 2003 we're seeing the dates on emails change. Where is that coming from?

We've deemed this acceptable in large part because the former questions (webdevs getting their environment set up) vastly, vastly outnumber the later questions.

The data we work with

For a good run-down of the type of data we most commonly work with, there is a very nice write-up over here on DiscoveryBrain.Those are the top twelve file-types we run into, and six of the twelve are Microsoft-specific file-types.

There is a long tail of other file-types we work with, which is where we get into how we're competitive versus other companies. We won a major contract a while back because we could natively handle Lotus Notes archives, rather than converting them to PST before processing like some other vendors. Things like that.

Processing all of those MS-Office files can be tricky to do with pure open-source tools. OpenOffice is very good at a lot of things, but there are some corner cases (or in some instances corner offices) where it doesn't yield very good results. So we may process with actual MS-Office, which in turn means we need Windows around.

Once in a great while we'll run into some Mac-specific formats. We can handle those too, though we don't do so with Macs.

We've even run into some Unix-specific formats. But the OSS support for those is rather strong, so those are pretty well handled.

But still. The vast majority of our processing is those twelve formats.
As a moderator on ServerFault I run into a lot of the iffy questions. Our users flag them for moderator attention and we deal with them. Some are obviously wrong enough to get dealt with through the normal close-voting process without the mod-hammer being involved. Along the way, we mods do run into some differing opinions on certain nuances of the FAQ. I'll be covering some of the more frequently misunderstood areas of that august document.

#3: Desktop Support
The FAQ states: "If your question is about... Desktop PCs that you maintain the workplace" and "not about... general personal computing troubleshooting"

This is perhaps the biggest gray area, vying with servers in the home for the top spot. There are a lot of varied opinions about this. A sizeable percentage of ServerFault's active close-voters and flaggers are of the opinion that all workstation stuff belongs on SuperUser, never mind what the FAQ says.

That said, for questions involving the technologies surrounding Desktop Support, such as Group Policy, Enterprise Anti-Virus, or SCCM questions, those are clearly topical and stay put. Questions about why Office 2010 is misbehaving on a certain Windows 7 machine? Those'll get migrated, though that's less likely if it is clear from the question that this is in a workplace, and even less likely if there are multiple stations impacted.

A key thing to keep in mind is that questions that are pure workstation troubleshooting are presumed to be asked by an end-user experiencing the problem, not the sysadmin handling it. These questions do not get the benefit of the doubt. There has to be something in the question to suggest this is a professional desktop-support situation.

Another big area that we get a lot of questions on are generic Linux support questions. Even though we have both AskUbuntu and Unix & Linux Stack Exchange sites, we still get a lot of questions from people looking for help. The thinking is probably like this

This is a lot of server people, and I see a lot of Linux questions. These folk know their stuff, I'll ask here.

Just because you're running Linux on your laptop does not make you someone who "manage or maintain computers in a professional capacity." You're a power-user. *I* am a power-user when I'm having trouble with the OpenSUSE install on my own laptop. Power-user questions go (in general) on Super User. Or AskUbuntu if its an Ubuntu question.

Unlike Windows desktop-support questions, the ServerFault community as a whole has a pretty consistent view of what Linux desktop-support questions we'll tolerate look like.
  • Does not involve consumer-looking hardware, like USB drives, optical drives, laptops, or other peripherals.
  • Does not involve multi-media or office software.
  • Does not involve install problems of common end-user distros, like Ubuntu. 
We'll give questions about home web-dev servers a good look first, but those may just be closed as off-topic.

One thing we never see are questions about supporting fleets of Linux desktops. I know they're out there, Novell made a point of advertising the fact that they do just that, but I haven't seen questions about that. If they come, they'll be welcome. To me the few Linux-desktop holdouts of old now all have Macs on their desks instead, but that may just be observer bias.

Enterprise Desktop-Mac support is something SF is not that good with. We do get questions about just that from time to time, and we just haven't attracted enough of the right answerers to handle those questions that well. Questions about general Mac troubleshooting get closed as off-topic, migrated to Super User, or if something is on the ball, mod-flagged for migration to the Apple Stack Exchange site.
As a moderator on ServerFault I run into a lot of the iffy questions. Our users flag them for moderator attention and we deal with them. Some are obviously wrong enough to get dealt with through the normal close-voting process without the mod-hammer being involved. Along the way, we mods do run into some differing opinions on certain nuances of the FAQ. I'll be covering some of the more frequently misunderstood areas of that august document.

#2: Networking in the home
The FAQ states simply, "and it is not about.. Networking outside the professional workplace."

As with servers, a lot of sysadmins do interesting networking things at home in order to keep their skills sharp. A decade ago I created a Linux firewall for my home network in order to allow such things as multiple computers behind it (my, have things changed in 10 years) and a way to SSH into my home network for various things. These days we're far more likely to throw something like DD-WRT or Tomato on the right off-the-shelf home router to do the same thing, and not bother with a 6 year old dinosaur PC.

These days, home networking sysadmins are exploring topics like how to get IPv6 tunneling to work, reaching strange places in their home with any number of networking technologies, and whatever remote-access methods seem appropriate given the family audience. Or focusing on info-security, some are even running honeypot-networks, various IDS systems, and outright malware research.

Interesting as they are, they're off-topic. The vast majority will get forwarded over to SuperUser where their very good home networking gurus will handle them. Just because a SysAdmin is doing it at home for professional development does not elevate them above "power user". The Super User FAQ states that it is for, "computer enthusiasts and power users," and when not being paid for what we do, us sysadmins are power-users at home.

It is very easy to see why such home networking questions end up on ServerFault. The reasoning goes something like this:

Hey, I've got an advanced networking question. It's all sysadminy, so I'll ask where the networking experts are!

While true, the question is still out of scope. If left to our own devices, a lot of these questions could be easily fielded by us, but we don't do that. That's a SuperUser thing, and some of us hang out over there too. That said, to someone who has a brain filled with BGP, L3+ routers, and other such networking arcana, DD-WRT questions can be just as baffling.

There are some things that are clearly out-of-scope for ServerFault:

  • Off-the-shelf home routers of any kind, no matter how modified.
  • Wireless problems in the home.
As with the servers-in-the-home problem, "Professional workplace" is a key differentiator here, and one missed by a lot of new askers.
As a moderator on ServerFault I run into a lot of the iffy questions. Our users flag them for moderator attention and we deal with them. Some are obviously wrong enough to get dealt with through the normal close-voting process without the mod-hammer being involved. Along the way, we mods do run into some differing opinions on certain nuances of the FAQ. I'll be covering some of the more frequently misunderstood areas of that august document.

#1:  Servers in the home

The FAQ states simply, "and it is not about... Running servers at home for personal use".

I have yet to run into a sysadminly professional that doesn't have at least some kind of server at home, even it is just a NAS holding the video collection. A large number of them run servers at home as a way to keep skills sharp, which is a good way to keep your hand in technologies you don't get to play with at work. I've run into several who run full up Active Directory domains at home because it's good practice, not because they feel it's needed on a network with five active users on it. I've known one or two who've run Exchange at home simply because it's good practice, not because it's the best mail solution for five people. All of these people have professional development on the mind.

This last bit is where the gray area appears. If you're doing it for professional advancement, perhaps you're studying for some major certification, then it isn't "personal use" now is it?

Opinion is split on this, but the large majority of voters who flag or close-vote believe that ServerFault is for servers in the workplace, not at home. Even if it is for professional development. If your home IS your workplace, maybe that'll work out, but we'll still twit you about getting some real hosting for your hardware.

Questions about getting your 20TB 1080p PVR/media-center able to stream decently fast across powerline networks will get closed as off-topic really fast. Even if it is an interesting problem.

Questions about figuring out how to get SharePoint 2010 working on three machines that were old in 2008 will get the question closed pretty quickly. Unless it is clear that this is at your job for some reason (no-budget non-profits do run some really old stuff!), that kind of thing will get closed. But, it'll probably earn a few answers from people before it gets shut down.

Questions about how to get a new interface blade installed into a four year old HP Blade Rack you have installed in a 22U rack you have in your basement will earn you some confusion, comments about tolerant house-mates, and eventual close-votes because it's in the home. Fail to mention the "basement" part and this kind of question would earn answers. Mention the 'basement' and you'll still earn some answers because that's some high grade kit (if old), and that lumps it into "professional" in some people's mind; but it'll still get closed because of the basement part.

Mentioning "home" in a question is a guarantee of three close-votes, and a 75% chance of a mod-flag. Mentioning true server-grade hardware may wave one or two off and reduce the probability of a mod-flag.

In the end, there are very, very few cases where a server in the home is topical. And even those will get close-votes.

  1. Your home IS your job. Some will question your professionalism, but it should survive.
And that's it, really. Everything else is on a case-by-case basis.

Look what I found up the street

| 1 Comment
I'd walked by here a number of times but hadn't been far enough away to notice that big sign up there.

That's the Blackboard HQ right there across the street from the NPR building. I knew it was around here somewhere, I just hadn't found it yet.