Re: [LAD] [OT] Richard Stallman warns against ChromeOS

From: Ralf Mardorf <ralf.mardorf@email-addr-hidden-dsl.net>
Date: Fri Dec 17 2010 - 12:05:57 EET

On Fri, 2010-12-17 at 10:36 +0100, Philipp Überbacher wrote:
> Excerpts from Arnold Krille's message of 2010-12-16 08:30:32 +0100:
> > On Thursday 16 December 2010 01:13:24 Dan Kegel wrote:
> > > On Wed, Dec 15, 2010 at 10:48 PM, gene heskett <gheskett@email-addr-hidden> 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,
> >
> > Arnold
>
> I guess it really depends on what you try to achieve. Afaik the average
> life-span of a HD is puny 2 years. From what I heard the magnetic tapes
> used by for example ESA a long time ago have a life-span of 80 years.

Those tapes might be very, very expensive. High speed to avoid
drop-outs, 2" or so and proved that the coats are absolutely perfect,
resp. doing the same backup on different batches of tapes, that were
produced on different times. On a coil, but a cassette. Wearhousing will
be very, very expensive too.

I hear audio tapes that are older than I'm and they were in a very good
condition and as I said before, I know professional video tapes that
were ruined, because BASF fault during the production of those tapes.

> If
> 'store it good and forget' is what you're after then tape seems like a
> good idea.
>
> As for my university, as far as I know they use some RAID system for
> everyday and tapes for sensitive data. And they already had their whole
> RAID fail at the same time.

Possible e.g. by lightning, because lightning protection is not safe or
just because of Finagle's law.

IMO for less data DVDRAM is good and for much data HDs are the best
media we could use, of cause those HD drives need to rest, when not in
use. I'm turning on my computer several times a day and my drives get
broken after 2 years.

IIRC somebody wrote that at his school they use HDs to backup, because
of the costs.

Btw. today I read the first time about
http://de.wikipedia.org/w/index.php?title=Datei:Mercury_memory.jpg&filetimestamp=20050221015907 :) and http://de.wikipedia.org/wiki/Trommelspeicher :).

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Dec 17 12:15:01 2010

This archive was generated by hypermail 2.1.8 : Fri Dec 17 2010 - 12:15:01 EET