Про распрделеленную флибусту

Вообще по-моему близким к идеалу протоколом для синхронизации многочисленных личных и семейных электронных библиотек является NNTP.

Пишешь список групп (категорий и жанров) которые тебе интересны, твой сервер стучится к соседскому и спрашивает "а вот GROUP такая-то у тебя есть?" Тот отвечает "IHAVE и список идентифкаторов произведений (в оригинальном NNTP - статей, здесь кни)". Наш сервер "О, SENDME вот это, вот это и вот это (а остальное у меня уже есть)" При этом есть и cancel messages, и понятие supercedes.

У fb2 правда аналог понятия supercedes встроенный. Там есть version.

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

Ну и вообще в качестве IHAVE вполне может выступать уже существующая система OPDS-каталогов. Нужно только к своей библиотеке приделать робота, который будет шариться по списку OPDS-каталогов и скачивать всё, что по его мнению может хозяина заинтересовать.

Но в распределенной системе существенно актуальной будет задача поиска информации. Это при наличии такого центрального хаба, как флибуста было хорошо. Все заливали книги на флибусту, а потом все скачивали с торрентов ежемесячные обновления. Это гарантировало что при относительно разумных затратах места и траффика у всех будет всё.

А вот как быть в распределенной системе? Держать весь каталог библиотеки в DHT? Как-то многовато по-моему будет. Особенно если учесть что для каждой книги придется держать довольно длинный список узлов, где она доступна. Или достаточно держать список групп? Жанров и категорий не так много. А там если тебе захотелось редкую книгу ну будешь перебирать сотни и тысячи серверов с данной группой. пока не найдешь такого, где она есть.

Потому что если попытаться организовать более-менее постоянный бэкбон (как было в юзнете), то скорее всего по нему начнут наносить удары. Как по распространителям нежелательной (не важно по соображениям копирайта или соображениям цензуры) информации.

Песня про тесты

Вот почему-то в голове у современных opensource разработчиков не укладывается, что тестировать программу надо не только на той системе, где она собрана.

(я уж не говорю что у многих разработчиков не укладывается в голове что крупный программный проект надо делить на рантайм и девел-пакеты, и если что-то там можно использовать при сборке, то надеяться на наличие этого на продакшн-системе совершенно опрометчиво. В постгресе таким pg_config).

Сегодня выяснилось что мезон подготавливая информацию для запуска тестов берет полные пути и пропивсывает их в бинарный файл meson_test_setup.dat. И как-то очень неудобно получается если у нас сборка на windows делается в одном jenkins-овском workspace, а тесты гоняются совсем в другом. Правда выяснилось что этот бинарный файл сделелан питноовским модулем pickle и расковырять его вполне реально. Ну вот почему pickle, а не json, yaml или результат питновской функции repr? В старо й сборочной системе под window конфиг Data::Dumper-ом писался.

Вообще у нас регулярно возникает эта проблема.

Мы собираем постгрес или там postgis каокй-нибудь для rhel, а протестировать надо кроме rhel, на rocky, alma и oraclelinux. Собираем для Alt SP 8.2, а тестировать надо и на 8.2 и на 8.4. И так далее. Даже виндов у нас в тестовой системе штук пять - 10, 11, 2016, 2019 и 2022.

А еще бывает какая-нибудь экзотика, которую хорошо бы протестировать на чужом железе. Например, на настоящем железном мейнфрейме или PowerDome. А у нас такого нет, надо тащить на железо заказчика или какого-нибудь интегратора. И как-то светить там наши исходники очень не хочется. А пойди запусти любые регрессионные тесты без исходников.