Re: Cloud Computing Smears (Was: Google Wave)

2009-10-25 Thread Deborah Harrell
 On Mon, 10/19/09, John Williams jwilliams4...@gmail.com wrote:

  Never underestimate the power of human error. As this
  debacle demonstrates.

  (me, IIRC) Which particular debacle would that be?

 I was referring to the Sidekick debacle:
 
 http://www.eweek.com/c/a/Mobile-and-Wireless/Microsoft-Claims-Sidekick-Data-Will-Be-Restored-This-Week-491196/

Whoops!  I have a friend who isn't using that service, but somehow lost all his 
hundreds of contacts from his phone, and they weren't retreivable from his 
back-up site either.  I, OTOH, have all my contacts on paper...(and I'd be smug 
about it except I don't have hundreds, just dozens, which is quite managable).

There _was_ something about a 'hole in security of cloud computing' in a recent 
MIT Tech update (but I only get the headlines, not the full story, and doubt 
I'd understand without some major studying, which I just don't have time for at 
this point...).

Debbi
Borderline Luddite? Maru   :)


  

___
http://mccmedia.com/mailman/listinfo/brin-l_mccmedia.com



RE: Cloud Computing Smears (Was: Google Wave)

2009-10-19 Thread Jo Anne
Julia wrote:

 (Jo Anne -- a RAID is a Redundant Array of Independent Disks, where the data
 is stored on multiple disks and checked for accuracy on some regular basis.
 If one drive goes down, either the data should be duplicated somewhere, or
 there should be enough information stored on another disk or disks to
 reconstruct what was lost.  Off-site backup is still recommended for things
 like fire, floods and tornadoes, and don't anyone laugh about the tornadoes,
 m'kay?)

Thanks, Julia.  I figured it was something like that and not a can of bug
spray.

Amities,

Jo Anne
evens...@hevanet.com




___
http://mccmedia.com/mailman/listinfo/brin-l_mccmedia.com



Re: Cloud Computing Smears (Was: Google Wave)

2009-10-19 Thread Deborah Harrell
 From: John Williams jwilliams4...@gmail.com

massive snip 
 Never underestimate the power of human error. As this
 debacle demonstrates.

Which particular debacle would that be?  We gotcher health care, Afghanistan, 
Eyerak, and balloon boys...

Take yer pik!

Debbi
Whaddya Expect From A Family On Wife-Swap Twice? Maru


  

___
http://mccmedia.com/mailman/listinfo/brin-l_mccmedia.com



Re: Cloud Computing Smears (Was: Google Wave)

2009-10-19 Thread John Williams
On Mon, Oct 19, 2009 at 12:42 PM, Deborah Harrell
harrellmed...@yahoo.com wrote:
 From: John Williams jwilliams4...@gmail.com

 massive snip
 Never underestimate the power of human error. As this
 debacle demonstrates.

 Which particular debacle would that be?

I was referring to the Sidekick debacle:

http://www.eweek.com/c/a/Mobile-and-Wireless/Microsoft-Claims-Sidekick-Data-Will-Be-Restored-This-Week-491196/

___
http://mccmedia.com/mailman/listinfo/brin-l_mccmedia.com



Re: Cloud Computing Smears (Was: Google Wave)

2009-10-18 Thread Bruce Bostwick


On Oct 18, 2009, at 12:25 AM, Max Battcher wrote:


On 10/18/2009 0:38, John Williams wrote:
On Sat, Oct 17, 2009 at 8:36 PM, Julia Thompsonf...@zurg.net   
wrote:
Er.  In that sort of a situation, I myself would set up a RAID for  
storing

the data, *much* less chance for losing it.


RAID does not protect from rm -rf / , which (some variant of) is my
guess at what happened. Although now they are saying most of the data
is recovered, so maybe it got munged in a reversible way.


Any cloud service at this point is going to be tens, if not  
hundreds, of servers. (Major services easily run in the thousands of  
servers, and if you count virtual servers the biggest services are  
using millions of servers already.) At this point any outage that is  
going to affect a service as whole is generally going to be a lot  
subtler (and possibly a lot nastier, such an accidental viral  
infection due to an underlying bug/exploit in the service) than a rm  
-rf /.


At least, assuming the system admins are doing their jobs correctly  
rm -rf / to a single server is extremely unlikely to cause massive  
outage or damage... (As a service gets large enough hard drives are  
expected to fail randomly, and surprisingly frequently, and services  
should be designed around that problem...)


And, as with a RAID except on a much larger scale, there's built in  
redundancy and error correction, so the system tends to self-heal.   
About the only threat is viral mechanisms that propagate through the  
system.


I'm just territorial about my data, is all.  I tend to like knowing  
where it's stored and who has access to it, and have some control over  
its persistence in some cases.  There are some applications for which  
I think cloud storage might serve my needs, and others for which I  
consider it unsuitable.


Oh yeah? Well, I speak LOOOUD, and I carry a BEEEger stick --  
and I use it too!  **whop!**   -- Yosemite Sam





___
http://mccmedia.com/mailman/listinfo/brin-l_mccmedia.com



Re: Cloud Computing Smears (Was: Google Wave)

2009-10-18 Thread John Williams
On Sun, Oct 18, 2009 at 9:42 AM, Bruce Bostwick
lihan161...@sbcglobal.net wrote:

 On Oct 18, 2009, at 12:25 AM, Max Battcher wrote:

 On 10/18/2009 0:38, John Williams wrote:

 On Sat, Oct 17, 2009 at 8:36 PM, Julia Thompsonf...@zurg.net  wrote:

 Er.  In that sort of a situation, I myself would set up a RAID for
 storing
 the data, *much* less chance for losing it.

 RAID does not protect from rm -rf / , which (some variant of) is my
 guess at what happened. Although now they are saying most of the data
 is recovered, so maybe it got munged in a reversible way.

 Any cloud service at this point is going to be tens, if not hundreds, of
 servers. (Major services easily run in the thousands of servers, and if you
 count virtual servers the biggest services are using millions of servers
 already.) At this point any outage that is going to affect a service as
 whole is generally going to be a lot subtler (and possibly a lot nastier,
 such an accidental viral infection due to an underlying bug/exploit in the
 service) than a rm -rf /.

 At least, assuming the system admins are doing their jobs correctly rm -rf
 / to a single server is extremely unlikely to cause massive outage or
 damage... (As a service gets large enough hard drives are expected to fail
 randomly, and surprisingly frequently, and services should be designed
 around that problem...)

 And, as with a RAID except on a much larger scale, there's built in
 redundancy and error correction, so the system tends to self-heal.  About
 the only threat is viral mechanisms that propagate through the system.

Never underestimate the power of human error. As this debacle demonstrates.

___
http://mccmedia.com/mailman/listinfo/brin-l_mccmedia.com



RE: Cloud Computing Smears (Was: Google Wave)

2009-10-17 Thread Julia Thompson
Er.  In that sort of a situation, I myself would set up a RAID for storing
the data, *much* less chance for losing it.  I'd just do that anyway.  In
fact, the computer that's still in a box and is destined to replace the one
I'm using right now has a RAID, because I seem to have a knack for
catastrophically losing hard drives that baffles my husband entirely.  (He
has more problems with his PDAs than I do, so I guess there's *some* sort of
balance)  I think I've lost 2 or 3 in the past 6 years, and any data
that wasn't backed up, which is kind of rough for an information junkie.
For *that* sort of application, I'd go with a decent number of disks in the
array for any one set of data.

My own problem with cloud computing is, if the magical set of wires between
me and my data has a glitch, I can't get to my data, and we end up with
Grumpy Julia, which is not pleasant for anyone directly involved.

(Jo Anne -- a RAID is a Redundant Array of Independent Disks, where the data
is stored on multiple disks and checked for accuracy on some regular basis.
If one drive goes down, either the data should be duplicated somewhere, or
there should be enough information stored on another disk or disks to
reconstruct what was lost.  Off-site backup is still recommended for things
like fire, floods and tornadoes, and don't anyone laugh about the tornadoes,
m'kay?)

Julia


___
http://mccmedia.com/mailman/listinfo/brin-l_mccmedia.com



Re: Cloud Computing Smears (Was: Google Wave)

2009-10-17 Thread John Williams
On Sat, Oct 17, 2009 at 8:36 PM, Julia Thompson f...@zurg.net wrote:
 Er.  In that sort of a situation, I myself would set up a RAID for storing
 the data, *much* less chance for losing it.

RAID does not protect from rm -rf / , which (some variant of) is my
guess at what happened. Although now they are saying most of the data
is recovered, so maybe it got munged in a reversible way.

___
http://mccmedia.com/mailman/listinfo/brin-l_mccmedia.com



Re: Cloud Computing Smears (Was: Google Wave)

2009-10-17 Thread Max Battcher

On 10/18/2009 0:38, John Williams wrote:

On Sat, Oct 17, 2009 at 8:36 PM, Julia Thompsonf...@zurg.net  wrote:

Er.  In that sort of a situation, I myself would set up a RAID for storing
the data, *much* less chance for losing it.


RAID does not protect from rm -rf / , which (some variant of) is my
guess at what happened. Although now they are saying most of the data
is recovered, so maybe it got munged in a reversible way.


Any cloud service at this point is going to be tens, if not hundreds, 
of servers. (Major services easily run in the thousands of servers, and 
if you count virtual servers the biggest services are using millions 
of servers already.) At this point any outage that is going to affect a 
service as whole is generally going to be a lot subtler (and possibly a 
lot nastier, such an accidental viral infection due to an underlying 
bug/exploit in the service) than a rm -rf /.


At least, assuming the system admins are doing their jobs correctly rm 
-rf / to a single server is extremely unlikely to cause massive outage 
or damage... (As a service gets large enough hard drives are expected to 
fail randomly, and surprisingly frequently, and services should be 
designed around that problem...)


--
--Max Battcher--
http://worldmaker.net

___
http://mccmedia.com/mailman/listinfo/brin-l_mccmedia.com