[LAD] [OT] Richard Stallman warns against ChromeOS

Arnold Krille arnold at arnoldarts.de
Thu Dec 16 07:30:32 UTC 2010

On Thursday 16 December 2010 01:13:24 Dan Kegel wrote:
> On Wed, Dec 15, 2010 at 10:48 PM, gene heskett <gheskett at wdtv.com> wrote:
> > Now, if we can just get a law that when I have ... issued the delete to
> > the server, it truly was deleted
> For what it's worth, Google's caution in promising deletion
> is probably because it's not quite sure how to do that
> quickly.  Users would be Very Very Angry if a disk outage
> or a fire in a datacenter resulted in the loss of their stored
> email, so Google probably has some sort of offsite backup
> arrangement, and that might complicate prompt deletion.
> ... yup,
> http://mail.google.com/support/bin/answer.py?hl=en&answer=7401
> says
> "residual copies of deleted messages and accounts may take up
> to 60 days to be deleted from our active servers and may remain in our
> backup systems."
> So, if you were google, would you use tape backup?  If so,
> how would you do that permanent deletion thing?  If not,
> how would you make darn sure you didn't anger users by
> losing messages during a disaster?

I don't think google uses magnet-tapes or similar for any backups except the 
vital core data of its business. Given the number and size of their data-
centers around the world, they just sync the data to a different part of the 
world an be done with it. Of course the deletion has to be synced to all 
remote-copies and probably also forwarded to older backups but once such a 
mechanism is implemented it should do the actual delete within a day...

There are even universities that decided against a new tape-library and in 
favor of a big stack of disks for long-term backup because these where 
cheaper, similar reliable and much faster for restore. And they don't need a 
special tape-library-managing app to access the data, a file-browser or the 
command-line is enough...

Have fun,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20101216/6096b0f9/attachment.pgp>

More information about the Linux-audio-dev mailing list