Hacker News Digest

К сожалению, я не вижу полного текста статьи для создания пересказа. В предоставленном фрагменте только заголовок "Rob Ricci: 'While cleaning a storage room, our staff found th…'" и ссылка на discuss.systems, но отсутствует основное содержание.

Для создания точного и ёмкого пересказа (~170 слов в двух абзацах) мне нужен полный текст статьи. Пожалуйста, предоставьте содержимое статьи, и я с удовольствием подготовлю для вас качественный пересказ в соответствии с вашими требованиями.

• Восстановление ленты Unix V4 (1973 г.) — первой версии, написанной на C, — может дать нам единственный сохранившийся образец кода той эпохи.
• Проект, в котором участвуют исследователи из университета Юты, подразумевает извлечение битовой копии с ленты и последующее распространение ее через GitHub под лицензией BSD-2-Clause.
• Поскольку лента хранилась в сухом климате, шансы на то, что данные уцелели, высоки; однако никто не может гарантировать, что 50-летняя лента 9-дорожечной записи не содержит ошибок.
• Даже если в итоге окажется, что часть данных утрачена, сообщество может в конце концов получить хоть какие-то фрагменты кода на C, что само по себе уже является сенсацией.
• Вопрос о том, какие именно части кода первоначально были потеряны, остается открытым — возможно, они были утеряны еще в 1970-х.

На месте катастрофы батискафа "Титан" была обнаружена SanDisk-карта памяти стоимостью всего $62, которая удивительным образом осталась целой после имплоузии. Несмотря на экстремальные условия давления и разрушения подводного аппарата, дешевый носитель информации сохранил данные, позволив экспертам восстановить 12 фотографий и 9 видео с экспедиции. Эти материалы могут предоставить ценную информацию о последних минутах полюса "Титана" до трагического события.

Восстановленные файлы не содержат записей непосредственно с момента имплоузии, что объясняется мгновенностью и силой взрыва. Карта памяти, вероятно, была повреждена или уничтожена вместе с батискафом в последние секунды. Тем не менее, факт сохранения столь дешевого электронного компонента после таких экстремальных условий стал неожиданностью для экспертов, подчеркивая надежность современных носителей информации даже в самых неблагоприятных обстоятельствах.

• Камера и карта памяти были в титановом корпусе, не подверглись разрушению и оказались в руках следователей.
• Шифрование реализовано через LUKS, ключ хранился в NVRAM, но не в TrustZone, что позволило NTSB восстановить данные.
• В отчёте NTSB указано, что камера была настроена на запись на внешний накопитель, поэтому никаких данных о катастрофе не обнаружено.
• Пользователи обсуждают, почему не используется встроенная защита от перезаписи на SD-карте, и почему не применяется более надёжное шифрование.
• Возникает вопрос, почему не используются чёрные ящики, которые могли бы обеспечить информацию о причинах катастрофы.

Архивисты и энтузиасты по всему миру спешат сохранить информацию с устаревших носителей, таких как дискеты, которые скоро станут нечитаемыми. В Кембриджском университете, например, команда из 20 человек оцифровывает документы Стивена Хокинга, включая его диссертацию, опасаясь, что магнитные носители могут размагничиться. Эта проблема не ограничивается академическими кругами: от Национального архива Великобритании до Би-би-си — все сталкиваются с риском потери данных на устаревших носителях.

Специалисты подчеркивают, что "цифровая темная эпоха" уже наступает, поскольку информация, созданная с 1990-х по 2010-е, может быть утеряна из-за отсутствия совместимого оборудования. В ответ на это энтузиасты, такие как Джейсон Скотт из Archive Team, активно сканируют и сохраняют данные с различных платформ, подчеркивая важность своевременного действия для спасения цифрового наследия.

• Обсуждение охватывает широкий спектр тем: от сохранения старых дискет и форматов 3" и 5.25" до долгосрочного хранения данных и проблем устаревших носителей.
• Участники обмениваются личным опытом, включая работу с KryoFlux, проблемы с чтением старых дисков и невозможность найти подходящие инструменты.
• Обсуждаются различные аспекты, включая размеры дискет, формат файлов, и даже такие вещи как стоимость и доступность инструментов для чтения таких носителей.
• Участники также затрагивают тему долговечности и надежности различных носителей и форматов, включая флоппи-диски, магнитная лента, оптические носители и даже бумажные носители.
• В конце обсуждение сдвигается к обсуждению будущего хранения данных и необходимости в долгосрочном планировании сохранения информации.

Автор столкнулся с критической проблемой при шифровании пула ZFS: после переноса зашифрованных снапшотов с промежуточного пула sneakernet обратно на основной old данные оказались нерасшифровываемыми. Оказалось, что ZFS неявно создаёт зависимость от encryptionroot — исходного пула, где данные были впервые зашифрованы. В данном случае этим пулом был sneakernet, а не old, поэтому при попытке расшифровать данные на old система не смогла найти нужный ключ.

Ключевая деталь: ZFS передаёт метаданные о encryptionroot при операциях send/receive, даже если данные отправляются в raw-формате. Это привело к тому, что после удаления промежуточного пула sneakernet данные на old стали недоступны, так как система искала ключ от уже несуществующего источника. Автору удалось восстановить доступ, модифицируя исходный код ZFS для ручного создания bookmark и обновления метаданных, что подчёркивает важность понимания внутренней работы encryptionroot перед выполнением сложных операций с шифрованием.

• Пользователи обсуждают сложности и риски использования нативного шифрования ZFS, приводя примеры потери данных из-за ошибок в управлении ключами и снимками.
• Поднимаются вопросы о сравнении ZFS с альтернативами (LUKS+mdadm, Storage Spaces), отмечая преимущества ZFS в эффективности сжатия и производительности, но критикуя его сложность и отсутствие дружелюбного интерфейса.
• Обсуждается важность тестирования резервных копий и необходимость осторожности при использовании зашифрованных наборов данных, особенно при смене паролей или ключей.
• Упоминаются случаи успешного использования ZFS в течение многих лет без потерь данных, но с оговорками о необходимости строгого следования документации.
• Критикуется reliance на Stack Overflow и ИИ для решения сложных задач, поскольку это может привести к необратимым ошибкам из-за некорректных советов.

• Tesla автоматически выгружает данные о крушении на свои серверы и тут же помечает их для удаления в машине, оставляя себе единоличный контроль.
• Хакер @greentheonly восстановил «удалённые» данные в Starbucks и показал, что Tesla сначала утверждала, что записи нет, а потом «внезапно» нашлась.
• Участники обсуждения сравнивают поведение Tesla с уничтожением блэк-бокса и требуют уголовной ответственности за сокрытие доказательств.
• Многие заявляют, что больше не купят Tesla и предлагают законодательно обязать всех производителей хранить данные аварий в независимом «чёрном ящике».