Looking at the results, I am incredibly grateful for the support you've shown to me. Of the 145 ballots received, I was the first choice of 60 people, and I appeared on a total of 128 ballots. That's simply amazing, and I see it as a clear message that the members of LOPSA want to see the kinds of changes that I outlined in my candidate statement (PDF warning). I'm going to work with the rest of the Board to do just that, because I feel that the good that the organization can do for our profession is untold. I'm excited about the future, and you should be, too.

I want to take a moment to thank you all for supporting me. Every person I've talked with about this has been amazingly kind and encouraging. All of my readers, Twitter followers, friends, and family have been very encouraging and supportive of me and my ideas. So thank you very much.

So, since I'm now a Board member, I need to be clear about things. Anything I write on this blog, or on my twitter stream, definitely needs to be interpreted as coming from me and me alone. Unless I cross post it here from the LOPSA site, it's not official. I don't speak for the LOPSA Board, nor for LOPSA as an organization. My opinions, varied as they may be, are my own. Just because I say something about System Administration doesn't mean or imply that the LOPSA Board feels that way.

Now that THAT'S out of the way, it's time to get to work. But first, I've got to finish my vacation. If you have questions or comments, post them below. I'll be continuing to check my mail and reply when I get a chance.

Thanks again!

Anyway, it's been no secret that the government can obtain information from these sites (and more!) - the Patriot Act in 2001 guaranteed that. What has come to light recently is a program called PRISM. As that Washington Post article says, this top-secret program was authorized by federal judges according to FISA (having to do with Foreign intelligence).

What PRISM does is apparently allow the National Security Agency (NSA) access to the providers' databases (probably through an API of some kind). Strangely enough, all of the providers have been claiming not to take part while the government has spent its time claiming that PRISM is legal. That's an uncomfortable disconnect.

But as I said, all of this is top-secret. You and I wouldn't even know of its existence if it weren't for Edward Snowden.

There's already a cultural issue with IT in a lot of organizations. We don't speak the same language as the rest of the business (which, by the way, is our bad - we need to work on fixing that in our culture). But this is a very, very high profile case, and a lot of companies have to be re-evaluating their inherent trust of the people in their IT departments.

What do we tell them? What can we tell them? In most cases, we do have the keys to the kingdom, and that they have to trust us. Certainly, strong cryptography plays a part in protecting data from external (and in many cases, even internal) entities, but the keys have to be stored somewhere. Someone has to do backups of data, and to perform file transfers, and read logs and fix email, and so on. We deal with extremely sensitive data every day in our professions.

There's very little that we can do to assure people that we're not going to steal or leak their data other than by being trustworthy and working according to an ethical professional standard of practice. I abide by the LOPSA and USENIX Code of Ethics, and if you practice in this profession, you probably should, too.

The question has come up as to whether Ed Snowden should have done what he did. Whether it was wrong or not. It's such a simple question with so many different answers, and we're all scratching our heads and rubbing our chins. LOPSA has issued a statement and made reference to the Code of Ethics, but they didn't take a stance (which, given the many many ways this could play out in the long term, might not be a bad thing).

Here's how I see it.

Professionally, I believe that Ed was in the wrong. Our code of ethics allows for promptly disclosing factors that might pose unexamined risks or dangers. It seems very clear to me that the NSA and the participating companies knew exactly what they were doing, and what the ramifications of it were. The clause that I just referenced begins with, "I will do my best to make decisions consistent with the safety, privacy, and well-being of my community and the public". I'm certain that Ed would argue that he was doing just that, but he (and we) don't know the full ramifications of making this program public.

If, and this is purely theoretical, but if PRISM was actually keeping "us" safe from people who wanted to harm us, then the exposure of it caused damage to those efforts. And I am every bit as cynical as you are, and we both suspect that it wasn't doing as much as they want us to believe it was doing. But we don't know what the ramifications will be, and neither did he. He had incomplete visibility into the workings of the program, and doesn't know the ramifications of his actions. And that's why he was wrong to do it, from a professional standpoint.

Now, speaking personally...I'm an American. I suspected, as have most of us, that the US government was able to spy on us, and that if they wanted to, they could tap our phones (legally or illegally - it's all the same if you don't get caught, right?) and I suspected that, given the aforementioned Patriot Act, this was happening on a wide scale. But I had no idea that so many companies were involved, and I didn't realize that they had been so intrusive into our lives. As I write this, the ACLU is suing to stop PRISM, and I support them in that. I'll probably support whatever the EFF does, too, honestly.

So how do I reconcile these two views? I don't think I can. I think that they're inherently irreconcilable, and that they have to exist concurrently, independently, in my mind. We're far from the only profession to deal with ethical dilemas - we're just the latest.

If you look at that last example, Engineering Ethics, you'll see a subheading for whistleblowing, mentioning that courts typically find in favor of the whistleblower. If you check the references, you'll find a link to the story of Shawn Carpenter, who worked as IT security in Sandia National Labs. Shawn reported cracking that he found across a swath of government computers, in Sandia as well as outside. He was fired (wrongfully, it was determined).

Whether this case turns out in a similar vein, and Ed is found by the legal system to be within his bounds as an IT professional or not, time will tell. In the meantime, now would be a great time to hang the System Administrators Code of Ethics up so that you can point to it and say, "I'm not going to steal your data because I follow this". There's even a poster version you can print out.

.@standalonesa Are you up for a little Q and A on twitter? I will Q you will A. ;-)

— Joseph Kern (@josephkern) June 9, 2013

I thought it might be fun, so for the next hour or so, Joe and I had a back and forth about system administration. I thought that it might be of interest to my readers, so here it is in a more readable format:

Joe Kerns: Q1. Do you feel that virtualization #sysadmin are becoming the new datacenter technicians?
Matt Simmons: Yes and no. It can't be turtles all the way down - your stuff has to exist on some hardware somewhere. But at the same time, lots of the functions that used to be provided by those datacenter techs are provided by virtualization admins. Also, virtualization admins are undoubtably required to have a wider, deeper knowledge set than the physical infrastructure admins.

JK: In some ways, virtualization makes hardware management easier, reducing old complexity in favor of new.
MS: I agree. And VM sprawl hasn't gone away, even though we have tools to help manage it.

JK: Speaking of Sprawl: Q2. How much longer do you see the current trend of OS virtualization continuing instead of service virtualization?
MS: Machine-level virtualization won't go away. App-level abstraction will eventually be nearly ubiquitous. So it won't be instead of, it'll be on-top of. It's easy to imagine tomcat servers that auto-cluster and form "swarms" for HA & performance. The current state of the art, in terms of sophistication, leads to this pretty naturally. Centralized state management and so on.

JK: This is the heart of the #noOps folks, which most #sysadmin have dismissed as a #developer pipe-dream.
MS: The ultimate goal of #NoOps may actually be realized some day for a certain set of use-cases. Certainly in limited situations. That's assuming we don't get strong AI, of course. Then all bets are off regarding personnelle decisions ;-) Even today, my University has a team dedicated to maintaining the A/C on campus. My house? Not so much.

JK: Do you think AI can take a front seat in Human Computer Interaction (#sysadmin stuff)? Or more of an expert system vision?
MS: The AI we have now? Only in the weakest way (suggesting when we've made mistakes, not necessarily making initial decisions). I'm not up on the state of the art, but to my knowledge, there's been no incredible breakthroughs.

JK: Q3: What would you suggest a jr #sysadmin focus on to develop their career for the next five years?
MS: Programming and configuration management. Get used to the concept of abstraction. Become comfortable w/ IPv6 & make friends.

JK: Programming? But that's for ... programmers? What's the benefit for a #sysadmin? #devilsadvocate
MS: #include "parables/buckets_vs_pipe.h" - seriously though, sysadmins get things done. Getting things done is our currency. Programming allows #sysadmin folks to do more in less time, thereby increasing our currency. That's completely leaving off reproducibility, reliability, portability, and several other 'ility's

JK: Now we are getting somewhere! It sounds like you're saying #sysadmin are unscientific, or lack good engineering principles.
MS: I have not yet begun to say that (with apologies to John Paul Jones). Is that something that you'd like to talk about? Because we can totally talk about that.

JK: Of course! I have seen a lot of cargo-cult behavior as a #sysadmin from users and experts alike. What's up with that?
MS: It's not cargo cult so much as superstition, I think. Cargo Cult implies someone is trying to replicate results someone more able got, by doing the things that they did. Users and admins spend considerable time and effort doing things that they have done which got results in the past. Does that make sense?

JK: Isn't this the very definition of unscientific thought?
MS: Well, "unscientific thought" pervades our existence as humans. Almost none of us spend our days doing science all the time. The difference is that it never occurs to some people to perform experiments or to test their assumptions ever. If you do #sysadmin work the way that you did #sysadmin work 5 years ago, you are doing #sysadmin work wrong.

JK: Q the Last: Game of Thrones are you a reader or a watcher?
MS: Watcher until next week, when I go on vacation and absorb myself in the blood and guts. I can't wait.

There you go. I hope you enjoyed it! If you have any follow-up questions, comment below!

$sourceVS = get-virtualswitch -vmhost SOURCE-HOST -name vSWITCH-NAME
$targetVS = get-virtualswitch -vmhost TARGET-HOST -name vSWITCH-NAME
$sourceVS | get-VirtualPortGroup | ForeEach-Object {
New-VirtualPortGroup -name $_.Name -VirtualSwitch $targetVS -VLanId $_.VLanId
}


Just make sure to change SOURCE-HOST, TARGET-HOST, and vSWITCH-NAME to the right strings and you're good to go. If you want to do a sanity check, add a Write-Host in front of the New-VirtualPortGroup command, and it'll print out the lines that it would have executed.

If you're from a Linux background like I am, you probably have a tendency to freak out because there aren't quotes around variables (particularly the $_.Name variable), but it's an object, and as in so many other cases, PowerShell manages to do the right thing.

There are a ton of people who are very, very mad at Microsoft because of their recent TechEd announcement. Basically, Microsoft is concentrating, in a large way, in being a managed service provider. They're still selling software, but they're concentrating on honing their hosted service offerings, and in the mean time, a lot of system administrators have expressed concern that Microsoft is saying "Screw You" to sysadmins, because they feel like Microsoft is intentionally making it unnecessary to have sysadmins doing the same thing they have been for 20 years.

I hate to say it, but "suck it up", because this is totally what's happening, and it's going to be better for (almost) everyone this way.

Look, I wrote over a year ago that the profession of system administration is fracturing. There are going to be the architectual people who do big-picture things, and there will be the physical infrastructure admins who deal with the lower layer issues. You'll notice that I didn't say anything in that article about mid-level Exchange admins, and that's because, in the future, roles like that won't exist like they do now. I'm not picking on Exchange. I could just as easily have said "MySQL admins".

It's certainly not that people will stop using the services, it's just that the administration of them will be largely abstracted away, and any other administration of the services will be done in bulk by the Exchange Admin at the MSP, not by someone at your company. Sure, someone at your company might be responsible for writing the software that ties your local infrastructure into the MSP's infrastructure, but it won't be a "sysadmin" as you currently recognize them. It'll be a programmer who knows operations, directed to do that by the infrastructure architect.

At best, infrastructures of a large enough scale will run their own internal abstractions ("clouds"), and administrators will use APIs to deploy instances, diving into the actual administration of services only when necessary, and only for extremely deep-knowledge related issues. If you don't think so, take some time and research OpenStack or even Microsoft's recent Azure Pack. The idea is that it becomes seamless for you to have infrastructure on your equipment, then migrate it to an external provider.

This model won't ever contain 100% of the infrastructures out there. For a lot of people, it still makes sense to run their own physical infrastructures in-house and to have the "normal" IT staff supporting them, and it'll continue to be that way for a long time. But as new companies come online, this new way of operating IT will become more and more common.

The bottom line is that it doesn't make sense to build out a new generic physical infrastructure anymore, beyond whatever is necessary to support your users' desktop machines. Using a hosted cloud provider for your business is better in almost every way, so if you want to future-proof yourself, learn AWS, learn Azure, learn Rackspace. Learn to code. Learn configuration management. Learn to let go of the way that things have always been, because they won't always be like that in the future.

One of the groups I'm involved with is the Ops-Education group on Google Groups. Carolyn Rowland submitted an email today mentioning a recent blog post by none other than John Allspaw, titled Always a Student: Operations and Systems Safety. It's a great read, and you should definitely check it out.

Anyway, this is something that I've spent some time thinking about, so I wanted to weigh in. I wrote the following as an email reply, but I thought that it might be of interest to people who read this blog, too.

John Allspaw has been at the forefront of learning from outside ourselves since forever - his training isn't in IT at all; he's got a Masters in Mechanical Engineering and worked on vehicle crashworthiness studies.

You absolutely have to learn from other disciplines if you want to be good at what you do. A lot of disciplines are better at what they do than what we do, and in some cases, we do the same kinds of things. Everyone in the DevOps / IT Admin profession has to do Usability Design, except most of us barely think about it. We run what are sometimes critical infrastructures that people's lives and livelihoods depend on. When things fall over, a post-mortem should be conducted to discover the actual cause of failure. And the people who aren't aware of these kinds of processes need to learn from the past and figure out how to apply it to their world.

That is one of the reasons that I liked The Phoenix Project, and I'm sure many of you did, too. It's not a guidebook so much as an inspirational story of how someone else did what you should be doing, too. Less "case study" than "parable", but you still need parables.

Engineers have been safely designing and building structures and vessels for a long time, and they've been getting better at it in recent years, too. New ideas in design and engineering, like the ones talked about in Risk Society, are changing the way that everyone thinks (or at least, the way that they should be thinking), and to be honest, it has changed in IT, too. The concept of "there can never be failure" to "failure is inevitable; make sure that we can control the failure modes" is probably the biggest one that I know of.

As it stands right now, there is no IT equivalent of the FAA, who makes sure that infrastructures are "air worthy", so to speak, or who sets requirements for infrastructure uptime and redundancy. Part of this is the degree of criticality that they have versus what we have. Our infrastructures fall over and usually, no one is in danger of dying. But that is rapidly changing, particularly in the web-scale community.

If AWS East falls over, does anyone die? No one is able to say "no" with any degree of certainty. You can say, "anyone who puts systems for hospitals or traffic lights in AWS is an idiot" (and you'd be right), but there is prima facie evidence that idiots exist. So you can't say that no one will die because AWS falls over. Does that imply fault?

Almost certainly not of  AWS engineers, but almost definitely of the "idiot" in question. You can read about the Hyatt Regency Walkway Collapse in 1981 that killed 114 people and injured 216. The engineers who had approved the final designs were convicted of gross negligence, misconduct, and unprofessional conduct in practicing engineering. The engineering firm employing them itself didn't get convicted, they did lose their license to be an engineering firm.

However, the AWS engineers need to be (and probably are) aware that outages of their infrastructure can cause more than financial damage to their clients, and that goes for all of us. I ran the infrastructure for a financial risk analytics service that had tens of billions of dollars under management. If I mistakenly took down a core router, what would the ramifications be? Financial, certainly, but what of the people who made decisions based on the data provided by my service?  Of the people who had invested in the firms that had hired us?

While we can't let that pressure squash us, we have to remain cognizant of the fact that a lot is riding on our critical infrastructures. I've seen several college of engineering departments that have a sign that says the equivalent of, "If you cheat in engineering classes, you will kill people later". We don't have that mindset yet with IT, but I think we should because eventually, we'll be responsible for infrastructure that will kill people if we get it wrong.

I hate to end like that, but I'm out of time, so I'll just say this:

Everything isn't bleak, we aren't destined to fail, and things can be great in the future. We need more science in our profession, we need more diversity in our profession, and we need to figure out how to reach out to the people who don't know that they're part of our profession.

Please comment below!

The polls will be open for the next two weeks, so read the candidate statements for the people running and vote!

Once again, my good friend Rikki Endsley will be moderating the (probably) 90 minute session. They are giving preference to women in the Washington DC area (or people who are going to be attending LISA anyway), so if you're in that region and this sounds like something that interests you, email lisa13gurus@usenix.org (or drop a line here, and I'll get the message to them).

Thanks!

LOPSA-East

But I've been doing good, fun things. For instance, on May 3rd and 4th, I went to LOPSA-East, which was yet another really great conference. There was somewhere around 150 attendees this year, and it was really nice to see everyone again from previous years.

Way back in October of 2011 (were some of you even born then?), I asked about a class on SSDs, to see if there was any interest. Well, in October of 2011, the earliest I could have done it was spring of 2012, and didn't get around to finishing the course before then, so spring of 2013 it was, and I taught the SSD class on Saturday afternoon. Only three years in the making. That's cool, right? :-D

If you were in my class, you probably have the slides from the USB key. If you weren't in my class, then you'll be happy to know that since I don't really intend to teach the class again (although if my feedback is overwhelmingly positive, I'll consider it), I opted to have it recorded, and whenever that goes live, I'll be linking to it from here and including my full slide deck, too.

Storage Field Day

At the end of April, I went to Denver to do Storage Field Day. I haven't had a chance to write about the things I saw yet, but I'm very excited to talk about what we saw with Pernix Data. If you want to see some cool ideas, watch the videos there. I'll write more as soon as I get time.

LOPSA stuff

We're still in the swing of the election season. You might have seen when I updated my earlier post that the LOPSA Live transcript had been posted. That was the first of two candidate sessions. The other is tonight at 9pm, so follow the instructions by Aaron Sachs for connecting to #LOPSA-Live on Freenode and come ask the candidates good, hard questions.

The election is coming up next month. I've posted my series of discussions on internal concerns (including membership numbers, member communications, and operational transparency. Starting tomorrow, I'm going to start posting discussions related to external concerns - we have a lot of problems with marketing and how we're seen externally...when we're seen at all. Make sure to watch for those blog entries, too.

LISA Training

I haven't posted anything about it here, but I'm working with Dan Klein to help get training ideas for LISA'13. For the past several years, I've been involved as a blogger at the LISA conference (along with Ben Cotton, Marius Ducea, Greg Riedesel, and many others. I'm planning on continuing that for as long as they'll have me, but it's also nice to be able to contribute to the program in some small way, too. This means that if there's training that you think LISA should have, but doesn't, let me know and I'll do my best to figure out how we can have it.

Actual, "I get paid to do this" work stuff

At work, we've been doing all kinds of things. I've now got a production vSphere cluster, a new Nimble storage box, I'm trying desperately to get new gear for my core switch (I'm going with a pair of Nexus 5548s and six FEX to go along), and I need to order more five or six server racks to replace some of the ones we have now.

I continue to be mystified by the way that academia works. Specifically, budgeting and deadlines. For reasons that I'm unable to fathom, in order to get things on this year's budget, I have to order hardware and have it delivered and in my space by the end of June. Not, "ordered and paid for". Ordered, delivered, and in my space. I've thought about it, and I can't come up with any kind of compelling reason for this rule. Anyone with more experience in academia than I have want to weigh in? I'm at a loss.

Personal Stuff

I've finally bit the bullet and decided to get LASIK.

I'm in a large-ish metro area now, and the technology has been continually developing for a couple of decades, and I think it's matured to the point where I'm cool with people cutting my eye open and burning part of it away using lasers. I can't be 100% about technology enhancing our lives unless I walk the walk and take advantage of it, so I'm doing it.

I went in last week for my "free consultation", which determined that I was an excellent fit for normal "LASIK" surgery. If my cornea had been too thin, I guess I could have gotten either LASEK or PRK, both of which work well but have a longer healing and recovery time. Turns out my cornea is just fine.

Also, can I just say - they have the coolest eye equipment I've ever seen there. I've worn glasses or contacts since elementary school, and I've lived in a dozen cities or so since then, so I've seen my share of optometry equipment, but man, the toys the LASIK guys have are nuts. I'm practically blind, so when they said, "take off your glasses and look in this machine, and you'll see a hot-air balloon", I thought, "please, I'll be lucky to see a blurry light". Sure enough, looking into the machine, it was blurry...for a second. Then, like a camera, it "autofocused" and just like that, they had nearly my exact prescription. Awesome!

So the whole "lasering my eyeballs" thing is happening tomorrow afternoon. I honestly can't wait. I've been thinking about it for years, and having it this close is really exciting. I'll make sure to update early next week with the results.

So there you go. That's what I've been up to. I'll try to get back to posting more regularly, and maybe even on topics that you care about! Wouldn't that be exciting? ;-)

We'll see. Thanks!

You might remember that I'm running for election, as well. My candidate statement is at that link, and I've written a series of articles on my LOPSA blog expounding on the internal concerns that I feel need more concentration by the Board.

Tonight would be a great time to get a feel for how the potential Board members feel about topics relevant to our profession.

I'll be reminding people to tune in via twitter prior to the meeting, so watch for it there. I'd really appreciate your support and your questions, so please come and take part. This is your profession, so start taking part in it now.

Edit: The session has finished and you can read the transcript here:
https://lopsa.org/content/lopsa-live-may-9-2013-candidate-forum-transcript.

I have worked very hard for LOPSA as a volunteer, but there are certain things that you can only do from inside "the machinery", as it were, so I'm throwing my hat in the ring, and I'm here to ask for your support.

Here is a brief overview of my history with LOPSA:

• Joined in February, 2009
• Joined the LOPSA-NJ chapter when I moved to New Jersey
• Volunteered as the marketing coordinator for PICC10 Conference in 2010
• Founded the LOPSA-NYC Chapter in 2010
• Served as the program chair for the PICC'11 Conference in 2011
• Founded the LOPSA Columbus chapter in 2011
• Was honored with the 2011 Chuck Yerkes Award for outstanding individual contributions to online forums
• Joined the Boston LOPSA Chapter in 2012

I have prepared a detailed candidate statement. It's eight pages, explaining what I want to do with LOPSA, and where I see problems with what LOPSA has been doing, and how we need to fix it. The biggest complaint against LOPSA is that there's no value for membership, and if you read that document, you'll see that I'm going to work with the other Directors to fix that. We can't just sit on the sidelines. The future of our profession is too important, and we, as an organization, need to start directing our own future.

Because eight pages is extremely long, I am going to be breaking down my candidate statement into chunks that are more easily digested and posting them on my blog on LOPSA.org. My first entry is up, announcing my candidacy. I'll be adding more in the coming days.

Thank you for the support you've already shown me, my blog, and the various efforts that I've made on behalf of LOPSA and system administration. I don't feel like I've done enough yet, but with your support, I can do more. If you are a LOPSA member, I would greatly appreciate your support in the coming election. If you aren't a LOPSA member yet, I urge you to consider joining. If you'll read my statement, you know that LOPSA is going to work on behalf of our profession, not just its members. By joining LOPSA now, you get to help that effort by volunteering your time to do really valuable work that will help a lot of people.

As always, if you have any questions or concerns, please comment below or send me an email at standalone.sysadmin@gmail.com.

Thank you,

Matt Simmons
Candidate for the 2013 LOPSA Board of Directors

If you can't see the embedded video, you can watch it at YouTube.

Also, the rest of the talks are in a playlist, so watch them all!

Here's the rest of the day's schedule (in Mountain time):

Wednesday, Apr 24  08:00-10:00	Exablox 
Wednesday, Apr 24  10:30-12:30	Cleversafe
Wednesday, Apr 24  13:30-15:30	Marvell
Wednesday, Apr 24  16:00-18:00	Cisco

The funniest part of the whole situation was that even if there were absolutely no changes, the sync still took 15 minutes. 15 minutes to not sync data? How? Well, because in order to know that you shouldn't sync data, you have to know what the files look like on each side, so basically, rsync inspected the metadata of each set of a half million files on each end, and sent the (compressed) results from one side to the other, then compared the two to see which files should get copied.

I had this much trouble with a half million files….you've got to wonder how companies with actual Big Data problems deal with it. More and more, they're moving to object-based storage solutions. That's what Cleversafe is offering, and as you can see in their case studies, there are some really big datasets living on their hardware.

The Cleversafe offering is actually presented through a series of three separate pieces of hardware, which function as specific parts of an involved cluster solution. The hardware is:

The dsNet Manager (which comes in two flavors: 2100 (offering the ability to manage up to 10PB per dsNet Manager) or the more hefty 3100 (which offers a whopping 100PB of storage under management).

The second piece of the puzzle is the Accesser (something that my spellcheck absolutely refuses to recognize). It's available in two models, as well: the 2100 (which can provide up to 75MB/s of throughput) and the 3100 (which gives an order of magnitude more throughput, at 750MB/s).

The final piece of the puzzle is the actual storage array that holds the data. These guys are the SliceStors, and the two models are 2210 (which holds 36TB raw) and 1440 (which holds 144 TB raw).

Object stores, how do they work? Kind of like portals. Speedy thing goes in, speedy thing comes out.

You don't (usually) address object stores by using anything so barbaric as a filesystem. You use an API, and in the case of Cleversafe, you use a REST API (which looks a whole lot like HTTP's GET, PUT, DELETE, and LIST commands. You $VERB an object in software (so if your software deals with objects like, say, files, you PUT the file into the object store with the API). You are returned an Object ID, which is a unique identifier, or a key that you can use to pull (or GET) the object that you stored.

On a (much) lower level, these devices are using Reed-Solomon Erasure Codes (that link goes to a PDF, and fair warning, you only really need the first dozen slides or so). Essentially, you have the need to store data across several data stores, so that even if you can't access some of the data stores, you can get your data back. This should sound very familiar if you know how RAID 6 works.

Well, as it turns out, you can do some matrix math with the data you want to store and the number of copies you need, and if you have n blocks of data, you can generate m "coding blocks", and distribute n+m blocks throughout the various storage arrays. In order to rebuild the object that you just dispersed, you just need to return n+a, where a is smaller than m - ANY blocks, as long as you've got that number required. Think about that for a second.

What you end up with is a very interesting solution, where the fastest blocks that get returned to you are always the right answer (because the answer can be derived from the contents of the blocks you got - always). If all the data is local, then you get all of the data quickly. If all of the data WAS local, but one of your local arrays blew up, and now half of the blocks of data are local and half are in Zimbabwe, then you still get the data, just not as quickly as you would have.

Erasure codes are definitely what life after RAID looks like, and it's great to see more solutions coming online built with this technique. In terms of the clustering, the SliceStors use Hadoop and MapReduce, technologies built to provide wide-spread data access and analytics. I've never had the chance to play with either of them, so I'm not as familiar as I'd like, so I'll definitely be paying attention when Cleversafe is talking about their architecture and capabilities.

Cleversafe will be the first presenter at Storage Field Day 3 in Denver, on Wednesday, April 24th, starting at 10:30am Mountain Time. You can watch live at Tech Field Day.

The overall purpose of this legislation is actually decent. The idea is that cybersecurity threats are more easily defensible if people share information about attacks. This is exactly the same idea as the RBL anti-spam lists that tons of people subscribe to. The problem is in the details, though.

The text of the bill isn't actually that long, but one of the things that you'll see on Page 9, is Section 1104b(4) is "Exemption from Liability". Here's the text:

1 (4) EXEMPTION FROM LIABILITY.—No civil or
2 criminal cause of action shall lie or be maintained in
3 Federal or State court against a protected entity,
4 self-protected entity, cybersecurity provider, or an
5 officer, employee, or agent of a protected entity, self-
6 protected entity, or cybersecurity provider, acting in
7 good faith—
8 (A) for using cybersecurity systems to
9 identify or obtain cyber threat information or
10 for sharing such information in accordance with
11 this section; or
12 ‘‘(B) for decisions made based on cyber
13 threat information identified, obtained, or
14 shared under this section.

So essentially, any efforts made to investigate attempted breaches are exempted from criminal or civil cases, so long as the efforts were made in good faith? Really? What kind of aggressive action does that exemption extend to? If I see attempted breaches of my web server, do I have free reign to trace the visitor back to the source and try to breach their security in return, so that I can try to determine if this is a bot attack or a concerted effort?

Under this provision, it seems like I do, and that I can't even be taken to civil court for damages caused during my "investigation". Does that seem right to you? It doesn't to me, either.

CISPA has passed in the US House of Representatives. Demand Progress has a campaign to ensure it dies in the Senate. If, after reading through the bill, you also agree that this isn't something that you want passed, then you should contact your Senator. If you aren't in the United States, this law still affects you, since you can't bring a lawsuit in the US against any entity that hacks you back...you know, in "good faith". The EFF has a page for non-US folks where you can sign a petition.

I'm not telling you what to think. I'm only telling you what I think. And I think this sucks.