Hacker News Digest

Home Assistant Cloud переименовывается в Home Assistant Link, чтобы лучше отражать суть сервиса и ценности проекта. Команда Nabu Casa считает, что термин «облако» ассоциируется с ростом цен, сбоями и сбором данных крупными технологическими компаниями, что противоречит философии открытого и приватного умного дома. Новое название подчеркивает, что сервис предназначен для простого и безопасного подключения устройств и сервисов без привязки к проприетарным экосистемам или обязательным подпискам.

Home Assistant Link остаётся полностью необязательным: пользователи могут продолжать использовать Home Assistant локально без каких-либо ограничений. Сервис предоставляет такие функции, как удалённый доступ, голосовое управление через Nabu Casa и резервные копии, но без скрытых условий или привязки к конкретным продуктам. Переименование направлено на то, чтобы вернуть доверие и прозрачность в онлайн-сервисы для умного дома, сделав акцент на простоте, приватности и свободе выбора.

Переименование Home Assistant Cloud в Home Assistant Link — не просто маркетинг, а попытка разграничить приватный, локальный подход от корпоративного облака. Сервис позиционируется как минимально доверенный безопасный туннель к локальному экземпляру HA, а не как облачное хранилище или вычисления. Он зависит от сторонней инфраструктуры (вероятно, AWS), но не хранит данные пользователей и предоставляет опциональные функции (STT/TTS), сложные для локальной замены. Большинство согласны, что название «Link» точнее отражает функцию: безопасное соединение, а не облако. Термин «cloud» в домашней автоматизации ассоциируется с платными,vendor-зависимыми решениями (Wink, Nest), тогда как Link — опциональный, недорогой и необязательный сервис, не нарушающий принципов локального контроля. Споры касаются отсутствия RBAC — некоторые считают его критичным для семей с детьми и переходят на MQTT, другие видят в нём избыточную сложность, отвлекающую от UX. Также обсуждается зависимость от DockerHub и сторонних репозиториев, что противоречит идее полной автономии, но большинство считают это несущественным по сравнению с моделью доверия. Пользователи советуют альтернативы: Tailscale, Cloudflare Tunnel, VPN, reverse proxy с Vouch Proxy или OAuth2-Proxy, шим-систему разрешений перед API как временное решение до RBAC. Большинство HA-установок работают локально без удалённого доступа, Link используется редко, но удобен для тех, кто в нём нуждается. Требования к end-to-end шифрованию и отсутствию контроля Nabu Casa встречают возражения: сервис не хранит данные, его можно заменить открытыми альтернативами, и он этически отличается от Wink или Nest. Однако перед доверием рекомендуется аудит сетевых вызовов на скрытый сбор данных. Переименование воспринимается как логичный шаг для устранения противоречия между заявлениями Paulus о нежелательности облачных продуктов и наличием сервиса с названием «Cloud», вызывавшим путаницу. «Link» лучше отражает роль сервиса как моста между локальным устройством и внешним интерфейсом, что подтверждается опытом пользователей в робототехнике и других проектах.

Переход Git 3.0 на SHA-256 в качестве алгоритма хеширования по умолчанию — это дорогостоящая ошибка, которая принесёт больше проблем, чем пользы. SHA-1, несмотря на теоретическую уязвимость к коллизиям, на практике никогда не приводил к реальным сбоям в репозиториях Git за два десятилетия использования. Вероятность случайной коллизии настолько мала (порядка 1,4 септиллиона файлов в одном проекте), что её можно пренебречь. Реальные атаки типа SHAttered требуют целенаправленных усилий и не угрожают обычным рабочим процессам.

Основной аргумент против перехода — колоссальная стоимость миграции: все существующие репозитории, инструменты, скрипты и интеграции, построенные вокруг SHA-1, потребуют обновления или полной переработки. Это вызовет глобальные сбои в CI/CD, инструментах анализа кода, системах резервного копирования и сторонних сервисах. Вместо радикальной смены алгоритма автор предлагает более разумное решение: добавить вторичную подпись на основе SHA-256 к существующим объектам Git, сохраняя SHA-1 как адресный ключ. Такой подход обеспечит криптографическую целостность без разрушения экосистемы, удовлетворит требования NIST и уберёт излишние нагрузки от механизмов обнаружения коллизий (sha1dc). В итоге, выгода от перехода на SHA-256 минимальна, а издержки — огромны и распространятся на весь мир разработки.

Переход на SHA-256 в Git 3.0 технически реализуем с обратной совместимостью, но сталкивается с практическими проблемами совместимости подмодулей и инфраструктуры, а не с криптографической необоснованностью. SHA-1 не является теоретической уязвимостью — атака SHAttered 2017 года доказала практическую возможность коллизий. Git не был затронут, потому что никто не пытался подобрать префикс git-blob. Коллизии позволяют внедрять вредоносный код, если два репозитория имеют одинаковый хеш коммита, но разное содержимое в рабочей директории. Fossil SCM перешёл на SHA3-256 за 6 дней после SHAttered, сохранив старые хеши и не требуя перестройки репозиториев — миграция возможна без поломки ссылок. Git-документация подтверждает наличие двунаправленного отображения между SHA-1 и SHA-256, позволяющего ссылаться на объекты по старым хешам, но ограничивает смешанные репозитории и подмодули. Linus Torvalds в 2007 году заявлял, что SHA-1 в Git — это не функция безопасности, а средство проверки целостности, что ставит под сомнение необходимость перехода ради «безопасности». GitHub пока не поддерживает SHA-256 репозитории; автор статьи, возможно, фальсифицировал скриншот интерфейса. Выбор формата по первому коммиту — разумное решение. Подмодули в SHA-256 репозиториях могут ссылаться на SHA-1 подмодули — тесты на Git 2.47.3 подтверждают, что это работает без ошибок. Предлагается использовать git2/git3 как алиасы для выбора хеш-алгоритма при инициализации репозитория, чтобы избежать случайного перехода на SHA-256 в старых средах. Компании и госорганизации, запрещающие SHA-1 по политике безопасности, вынуждают Git перейти на SHA-256 не из-за криптографических угроз, а из-за требований сертификации. Утверждение, что SHA-256 — это «новый IPv6», опровергается: переход не требует полной замены инфраструктуры, а использует маппинг хешей, что делает его менее разрушительным. Хеш-коллизии в Git не являются проблемой для большинства пользователей, так как они используют сокращённые хеши (7–10 символов), а не полные, и не полагаются на них как на криптографические доказательства. Атака «Shambles» — это chosen-prefix collision, ближе к second-preimage, чем к обычной коллизии, и поэтому представляет более серьёзную угрозу, чем утверждает автор статьи. Предлагается хранить оба хеша (SHA-1 и SHA-256) в репозитории после миграции, чтобы старые ссылки не ломались, как это делает Fossil SCM. Математическая вероятность случайной коллизии SHA-1 в одном проекте — 1.4 септиллиона файлов, но это не учитывает целенаправленные атаки, которые требуют лишь тысяч вычислений. Переход на SHA-256 — это не только вопрос безопасности, но и инфраструктурной устойчивости: Git должен быть готов к будущим сменам хеш-функций, а текущий подход не обеспечивает криптографической гибкости.

Резервное копирование — это не просто копирование файлов, а сложный процесс, требующий учёта множества факторов. Важно не только иметь копию данных, но и обеспечить возможность восстановления в нужный момент времени, что подразумевает использование снапшотов и соблюдение Recovery Point Objective (RPO) — максимально допустимого объёма потери данных. Например, для фотосемейного архива достаточно еженедельных бэкапов с RPO в сутки, тогда как критические системы требуют RPO менее 30 секунд. Хранение множества снапшотов увеличивает нагрузку на хранилище, поэтому необходима ротация бэкапов по схеме вроде GFS (Grandfather-Father-Son), чтобы балансировать между полнотой истории и расходом места.

Кроме того, резервная копия должна быть изолирована от основной системы, иначе она уязвима перед теми же угрозами: ransomware, случайное удаление или destructive скрипты. RAID 1 не подходит, так как является зеркалом, а не точечной копией во времени. Нужно также учитывать консистентность данных при снапшоте — особенно если задействованы базы данных и приложения, работающие с ними одновременно, иначе можно получить несовместимые состояния. Внешние зависимости вроде LDAP, символических ссылок или sparse-файлов также могут сломать восстановление, если не поддерживаются инструментом бэкапа. В итоге, надёжная система подразумевает зашифрованные, deduplicated на уровне чанков, point-in-time архивы, соблюдение правила 3-2-1 и регулярное тестирование восстановления — например, раз в полгода. И да: лучше не запускать бэкапы в 2–3 часа ночи из-за рисков с переходом на летнее/зимнее время.

Резервное копирование — это инженерная задача, где успех измеряется восстановлением данных, а не наличием архивов. Проверка восстановления — основа надёжности; без тестов бэкапы бесполезны. Для большинства задач достаточно: - ZFS с снапшотами и rsync.net или sanoid/syncoid (90% потребностей: целостность, инкрементальность, простота восстановления). - Restic + Backrest для CoreOS (дедупликация, шифрование, совместимость с контейнерами). - tar | zstd | gpg с инкрементальным индексом GNU tar — портативное решение для локальных бэкапов. - rsync с ежедневной синхронизацией и ежемесячным полным пересозданием — проверенное десятилетиями решение. - Syncthing в треугольной схеме между устройствами в разных странах — отказоустойчивость без проприетарных форматов. - Proxmox Backup Server — единственная система, проверенная в продакшене. Для баз данных: точка восстановления требует согласованности — снапшоты БД и приложения должны делаться одновременно, иначе данные будут несогласованными. Мониторинг: healthchecks.io эффективно отслеживает сбои ZFS scrub, снапшотов и restic-бэкапов. Для фото и видео: 3-2-1-бэкап (телефон, локальный сервер Immich, Google Photos) — разумный компромисс для обычного пользователя. Критически важно: - Не хранить бэкапы в одном месте (физическая изоляция обязательна). - Не запускать бэкапы в 2–3 утра (риск сбоев из-за смены часовых поясов и перехода на летнее/зимнее время). - Разделять данные и приложения — если данные хранятся только в томах, бэкапить проще. Большинство пользователей недооценивают восстановление: бэкапы без проверки — иллюзия безопасности. Спор: некоторые считают, что 99% людей не делают бэкапы, и это оправдано — риск низкий, восстановление сложно без инфраструктуры, данные не ценны. Другие настаивают: потеря семейных фото — катастрофа, и даже простой бэкап (например, CCC или rsync) уже спасает.

В конце 2023 года у Tailscale появилась система‑широких сбоев, вызванных редкой формой повреждения SQLite‑базы. Инциденты начались в августе, когда резервные копии, сохраняемые каждые несколько минут в S3, начали падать: PRAGMA integrity_check фиксировал повреждение, а восстановление требовало ручного ввода нескольких конфигураций. За полгода было зафиксировано 19 повторяющихся случаев, пока не выяснилось, что виновником стал баг в самом SQLite, связанный с особенностями WAL‑режима и агрессивным чекпоинтом.

Ключевой факт — SQLite не предназначен для одновременного чтения и записи в режиме «многократных» контрольных точек; при слишком частых сохранений он может «перезаписать» журнал и повредить файл. Команда обнаружила, что в их конфигурации WAL‑файл сбрасывается в момент, когда открывается новый процесс‑чтение, что приводит к гонке условий. Исправив настройку резервного копирования и добавив небольшую задержку перед сбросом WAL, они устранили проблему, а также подготовили патч для ядра SQLite, который будет включён в будущие версии. Теперь сервис стабилен уже несколько месяцев, а команда планирует более тщательно тестировать любые нестандартные схемы использования «скучной» технологии.

Тред анализирует выявление 16-летней ошибки в SQLite, подчеркивая важность тщательного тестирования и поддержки открытого исходного кода. Участники отмечают значимость этого открытия и ценят прозрачность команды Tailscale в публикации результатов. Некоторые рекомендуют использовать Postgres для систем с высокой конкуренцией, считая SQLite неоптимальным выбором, другие оспаривают эту позицию.

Судя по данным, жесткие диски действительно стали надежнее. Исследование Backblaze, ведущего поставщика облачных сервисов, показывает, что современные диски служат дольше и стабильнее работают в течение жизненного цикла.

Первоначальная модель "ванны" (bathtub curve) предполагала три фазы: ранние отказы, стабильный период и рост отказов по мере износа. Но данные Backblaze за 13 лет показывают, что современные диски начинают с минимальным числом ранних отказов, затем работают годами без сбоев, и только позже начинают увеличивать частоту отказов. Это больше похоже на пологий склон, чем на ванну.

В частности, средний возраст дисков в пуле Backblaze увеличился с 6-8 месяцев в 2013 году до 6-7 лет в 2024. При этом годовая норма отказов снизилась с 6,39% в 2014 году до 1,17% в 2024. Это демонстрирует значительное улучшение надежности, даже с учетом роста объема данных и изменения состава пула дисков.

Основные выводы:

• Современные диски имеют минимальные ранние отказы, что указывает на улучшенный контроль качества.
• Период стабильной работы удлинился, иногда до 8 лет и более.
• Даже при увеличении срока службы, годовая норма отказов снижается, что подтверждает улучшение надежности.

Это подтверждается данными Backblaze, которые включают миллионы дней работы диска. Тенденция ясна: диски не просто служат дольше; они стабильнее на протяжении всего срока службы.

• Обсуждение охватывает широкий спектр тем: от анализа отказов жестких дисков и их долговечности до стратегий резервного копирования и восстановления данных, включая использование ZFS, RAID и облачных хранилищ.
• Участники обмениваются личным опытом и мнениями о надежности различных производителей и моделей HDD и SSD, а также обсуждают влияние условий эксплуатации на срок службы накопителей.
• Обсуждаются практические аспекты, такие как стоимость, энергопотребление и плотность хранения данных, а также влияние технологических усовершенствований на эти параметры.
• Участники также затрагивают тему долгосрочного хранения данных, включая использование оптических носителей, магнитной ленты и облачных сервисов, и обсуждают их достоинства и недостатки.
• В обсуждении также поднимается вопрос о том, какие факторы влияют на отказы накопителей и какие меры можно предпринять для обеспечения целостности данных, включая использование корректных файловых систем и регулярное тестирование состояния накопителей.