Hacker News Digest

Perkeep (ранее Camlistore) — это набор открытых форматов, протоколов и программного обеспечения для моделирования, хранения, поиска, обмена и синхронизации данных в пост-ПК эру. Система позволяет навсегда сохранять любые данные — от файлов и твитов до видеофайлов объемом 5 ТБ, с доступом через телефон, браузер или FUSE-файловую систему. Проект активно развивается, и хотя он уже полезен для технических пользователей, стоит быть готовым к ошибкам и незавершенным функциям.

Основные принципы Perkeep: полный контроль пользователя над данными, открытый исходный код, паранойяльное отношение к конфиденциальности (все приватно по умолчанию) и отсутствие единой точки отказа. Разработчики стремятся обеспечить сохранность данных на протяжении 80 лет. Последний релиз — версия 0.12 "Toronto", выпущенная 11 ноября 2025 года. Для технических пользователей доступны инструкции по установке, а также видео-демонстрации с конференций LinuxFest Northwest 2018.

• Обсуждение в основном вращается вокруг Perkeep (Perkeep), его философии «хранить всё навсегда» и причин, по которым проект не стал мейнстримом.
• Участники сравнивают Perkeep с традиционной файловой системой, поднимают вопросы о практичности и удобстве использования.
• Некоторые упоминают альтернативы вроде git-annex, ArchiveBox и SingleFile, но консенсуса по поводу «серебряной пули» нет.
• Обсуждение также затрагивает болевые точки: отсутствие у Perkeep интеграций с телефоном и облачными сервисами, а также его способности обрабатывать большие объемы данных.
• В целом, участники сходятся во мнении, что идея «вечного хранилища» остается привлекательной, но ее реализация в виде Perkeep не решает насущные проблемы, и сообщество в целом скептически настроено по отношению к перспективе «единой платформы для всей вашей цифровой жизни».

git-annex — управляет большими файлами в git, не храня их содержимое. Поддерживает синхронизацию, резервное копирование, шифрование и работу офлайн.

Для любителей командной строки — полный функционал; для остальных — git-annex assistant превращает всё в простую синхронизацию папок.

Быстрый старт

• установка
• обзор
• советы

Ключевые темы

• как работает
• специальные remotes
• сценарии
• предпочтения содержимого

Примеры

Архиватор Боб хранит данные на множестве отключённых дисков. git-annex показывает, где лежит нужный файл, и позволяет безопасно переупорядочивать дерево. Ночью cron-команды добавляют новое и отслеживают дубликаты.

Кочевница Алиса синхронизирует ноутбук, USB-диск, сервер и облако как git-удалённые репозитории. В самолёте или кафе она выбирает, что скачать, что удалить, а при подключении всё автоматически сливается обратно.

• git-annex отлично подходит для персонального управления большими файлами на множестве носителей, включая офлайн-диски, и гарантирует контроль целостности.
• Пользователи жалуются на сложность освоения, «тяжёлый» Haskell-стек зависимостей и проблемы с плагинами облачных провайдеров.
• В много-юзерных репозиториях «магические» ветви git-annex плохо масштабируются; для коллаборации чаще выбирают Git-LFS.
• Крупные репо (десятки ТБ и сотни тысяч файлов) замедляются до минут ожидания на каждую операцию, особенно при дефолтных «параноидальных» проверках.
• Git-annex и LFS решают разные задачи: первый — распределённое резервное хранение, второй — версионирование больших файлов в dev-репозиториях.

Большие файлы — давний враг Git: раздувают репозиторий, замедляют клонирование и дорого обходятся хостингам. С 2015 г. GitHub предлагает Git LFS, но он влечёт vendor-lock, плату за хранение, сложности отката и необходимость ставить расширение всем участникам.

Сегодня можно обойтись без LFS:

• Partial clone (--filter=blob:limit=100k) скачивает только нужные большие файлы, ускоряя клонирование в 30–50 раз и уменьшая дисковый след до размеров LFS-чекаутов.
• Недостаток: команды вроде git blame требуют до-загрузки, но для PNG-файлов это редко нужно.

Будущее — large object promisors:
Git-сервер будет прозрачно выгружать большие объекты в специальный remote, избавляя пользователей от LFS и хостинги — от лишних затрат.

• Критикуют Git LFS за «проприетарность», но многие отмечают, что протокол открыт и работает и с GitLab, и с S3.
• Основные боли: сломанные офлайн-режимы, многократная аутентификация, высокие расходы на трафик и неочевидные команды при клоне.
• Альтернативы — git-annex, DVC, Oxen, datamon и просто «не класть большие файлы в git», а хранить их в Artifactory.
• Часть участников ждёт нативную поддержку больших файлов в самом Git, чтобы не помнить про --filter=blob:none и LFS-указатели.