Кто-то на GitHub Actions сделал автоматизацию, которая собирает FFmpeg для сотни платформ: https://github.com/BtbN/FFmpeg-Builds
В процессе сборки она скачивает FFmpeg и все его зависимости, включая GNU gmp. Исходники берёт самые свежие, и у GNU gmp они лежат в Mercurial.
Сервера у GNU gmp не держат такую огромную нагрузку (отдать несколько гигабайт за несколько часов), и источник нагрузки начали банить: https://gmplib.org/list-archives/gmp-devel/2023-June/006164.html
Злого умысла у FFmpeg-Builds нет.
Предположим, что некто решает задачу автоматического анализа бинарников, например с целью выявления нарушений GPL. Он строит pipeline, на вход которому дают исполняемый файл, а на следующем этапе происходит поиск исходников, периодически приводящий к скачиванию их с серверов GNU. Будет ли подобный бан на стороне серверов GNU нарушением GPL (ведь лицензия требует предоставить исходники пользователю программы)?
Перемещено crypt из feedback
Если так происходит всегда то это опять таки свидетельствует о том что гит либо не децентрализован, либо это очень плохая децентрализация.
Не всё ли равно децтрализованной системе по какому транспорту общаются отдельные ноды, это влияет только на одно - по кому именно маршруту будет доставлено отправленное сообщение.
Вообще это твоё пояснение натолкнуло на мысль что гит децентрализован также как мессенжер у которого есть просмотрщик чатов, но нет сетевой части для обмена сообщениями, вместо этого создаётся текстовый файл, а пользователь уже сам как-нибудь разыщет адресата и доставит файл.
Это выглядит может и идейно правильно, но при отсутсвии прямой свзи с получателем сообщения выглядит довольно комично.
Может гит всёж научится в сортировку и автопересылку писем?
@kmeaw так что скажешь о двух предыдущих постах?
Увы, не знаю, что такое sendxml/sendjson.
Большая часть этих идей существует с времён FidoNet, когда мейлер, тоссер, редактор - отдельные программы. Сортировка и автопересылка писем там есть.
Если рассматривать классический email поверх SMTP, то есть git-send-email, а большинство MTA поддерживают .forward, откуда можно вызвать скрипт для разбора таких писем и применению патчей (git-am) из них в remote-ветки. Получателем таких писем может быть mailing list, рассылающий широковещательно письма, как это часто происходит в крупных opensource-проектах (например в ядре Linux).
Отсутствие прямой связи сейчас может и выглядит комично, но offline-протоколы всё ещё востребованы. До сих пор на Земле есть места, где связь очень так себе или появляется не всегда, а с расширением на космические масштабы проблема связи вообще становится неизбежной. Тот же TCP с дефолтными таймаутами и congestion control до Марса просто сломается.
Из интересных распределённых систем хранения (и поиска) стоит отметить IPFS, Tahoe-LAFS, YaCy. Я не знаю, как (и вообще ли) сделана в них защита от плохих участников - что случится, если кто-то будет отвечать медленно и/или неправильно.
Другая проблема в отсутствии общепринятого протокола для обмена статически типизированных данных между программами - большинство утилит командной строки в unix-пободных системах потребляют и порождают plain text, что не всегда удобно для сложных композиций. Некоторые умеют JSON, но нигде не описывают схему. Некоторые - XML. В корпорациях и модных cloud-native программах любят Protobuf (и gRPC). Для чтения людьми хороши recfiles - если бы мне нужно было выбрать формат описания артефактов для большой сети друзей, я бы начал именно с него.
Ещё интересный вопрос - что делать, если индексы очень большие, и вынуждают поисковую систему не скачивать сам индекс, а распределять пользовательские запросы на все системы, где потенциально могут быть искомые данные - насколько богатые запросы стоит разрешать? В мире веба похожую задачу решает GraphQL - он позволяет запрашивать, изменять или подписываться на изменения коллекций данных на удалённой машине и поддерживает фильтрацию и по вложенным полям, что обычно транслируется в запросы к локальной реляционной или объектной базе.