The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Tom Perrine <tom.perrine+tuhs@gmail.com>
To: Ron Natalie <ron@ronnatalie.com>
Cc: tuhs@tuhs.org
Subject: [TUHS] Re: Setting up an X Development Environment for Mac OS
Date: Fri, 27 Jan 2023 13:42:17 -0800	[thread overview]
Message-ID: <CAJq=PCUbBT0GRoc4_QAGxy1x8d59V-QsirOze6fz=9dUv3gaPw@mail.gmail.com> (raw)
In-Reply-To: <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]

A tiny bit of a fork, but...

When I was at SDSC.EDU we did a project for the National Archives. Gotta
love an agency that's mission is "data for the lifetime of the Republic"...

They wanted to be sure that they could still access data at least 100 years
later, even assuming that no one had accessed it in that 100 year period.

Anyway, we looked at all the options at the time (very early 2000s).

While media lifetime was indeed understood to be critical, we specifically
called out needing to retain the software and the encryption keys. AND the
encryption algorithms!
At that time, media encryption was still quite new, and they hadn't
considered that issue. At all.

Overall, the best, most practical approach (at that time) was to
periodically copy the data forward, into new media, into new
storage software, and decrypting with the old keys and algos, and
re-encrypting with new.

Only by doing this periodically, we argued, could they really be sure of
being able to recover data 100+ years from now.

Don't get me started on the degradation of early generation optical media
that was guaranteed for 50 years, but rusted internally within 2 years.

And of course now there are companies that specialize in providing
mothballed obsolete tape and other readers.

--tep



On Fri, Jan 27, 2023 at 6:55 AM Ron Natalie <ron@ronnatalie.com> wrote:

> When I worked in the intelligience industry, the government spent a lot
> of money tasking someone (I think it was Kodak) to determine the best
> media for archival storage.    It included traditional 6250 9 track
> tapes and the then-popular exabyte 8mm (which was atrociously short
> lived).   I pointed out that magnetic storage was probably always going
> to be problematic and things needed “digital refresh” if you really
> wanted to keep them.
>
>
> If you know the tape may be problematic when played back, there are
> things you can do.    I was gifted the master tapes of one of the radio
> shows originated at WJHU in the 70’s.   I had them sent out to a company
> who “baked” them, but then they also had to redo all the splices on them
> when they were played back.
>

[-- Attachment #2: Type: text/html, Size: 2794 bytes --]

  parent reply	other threads:[~2023-01-27 21:43 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 20:38 Noel Chiappa
2023-01-25 21:25 ` Clem Cole
2023-01-26  6:30   ` Lars Brinkhoff
2023-01-26 10:56     ` Ralph Corderoy
2023-01-26 12:01       ` arnold
2023-01-26 13:25         ` Lars Brinkhoff
2023-01-26 15:28       ` [TUHS] " josh
2023-01-26 16:07         ` [TUHS] " segaloco via TUHS
2023-01-26 16:48           ` emanuel stiebler
2023-01-26 21:19             ` segaloco via TUHS
2023-01-26 22:51               ` Andy Kosela
2023-01-27  0:48                 ` segaloco via TUHS
2023-01-27  4:07                   ` Will Senn
2023-01-27 14:08                     ` Chet Ramey
2023-01-27 14:49                       ` Ron Natalie
2023-01-27 15:53                     ` Dan Cross
2023-01-27 16:12                       ` [TUHS] NEXTSTEP 486 [was " Charles H Sauer (he/him)
2023-01-27 14:17             ` [TUHS] " Ralph Corderoy
2023-01-27 13:56         ` Ralph Corderoy
2023-01-27 14:54           ` Ron Natalie
2023-01-27 16:10             ` Larry McVoy
2023-01-28 22:15               ` Dave Horsfall
2023-01-29  0:31                 ` Kevin Bowling
2023-01-29 11:07                   ` emanuel stiebler
2023-01-27 21:42             ` Tom Perrine [this message]
2023-01-28  2:18               ` Larry McVoy
2023-01-28  2:49                 ` Tom Perrine
2023-01-26  6:32 ` Lars Brinkhoff
2023-01-26  9:45 ` emanuel stiebler via TUHS
  -- strict thread matches above, loose matches on Subject: below --
2023-01-25  1:46 [TUHS] " Will Senn
2023-01-25  7:45 ` [TUHS] " segaloco via TUHS
2023-01-25  8:00   ` Lars Brinkhoff
2023-01-25 16:41   ` Rich Salz
2023-01-25 19:53     ` Theodore Ts'o
2023-01-25 20:04       ` Dan Cross
2023-01-25 20:23         ` Larry McVoy
2023-01-25 20:27           ` Chet Ramey
2023-01-27  4:49         ` Theodore Ts'o
2023-01-27 18:05           ` Henry Mensch
2023-01-27 18:24             ` Charles H Sauer (he/him)
2023-01-26 13:17       ` Marc Donner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJq=PCUbBT0GRoc4_QAGxy1x8d59V-QsirOze6fz=9dUv3gaPw@mail.gmail.com' \
    --to=tom.perrine+tuhs@gmail.com \
    --cc=ron@ronnatalie.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).